Harte Nuss: Debian erfindet umask

07/07/2014 - 20:27 von Peter Mairhofer | Report spam
Hi,

Manchmal gibt es Dinge die sind wirklich Magie. Oder man sitzt zu lange
davor?

Debian 7 jedenfalls "erfindet" fuer einen bestimmten User eine default
umask von 0007. Nicht nur, dass diese "verrueckte" umask nirgends
vorkommt, ich hab alles gecheckt, was rein logisch die umask setzen koennte.

Hat jemand irgendwelche Tipps?

Wenn ich mich als User "peter" anmelde habe ich die umask "0007":


$ umask
0007

Im System ist als Default aber 027 konfiguriert:

# grep -i umask /etc/login.defs
# UMASK Default "umask" value.
# UMASK is the default umask value for pam_umask and is used by
# 022 is the "historical" value in Debian for UMASK
UMASK 027
# Other former uses of this variable such as setting the umask when


Nun eine Liste an was es allem nicht liegt:

1.) Nur Benutzer "peter" erhaelt die komische umask - andere User und
root wie gewuenscht 027

2.) ein "su" von root reicht um 007 zu bekommen

3.) Natuerlich wird sie *nicht* ueber irgendwelche dot-files im
Userprofil gesetzt: Ein entsprechendes grep liefert keine Ergebnisse und
um ganz sicher zu gehen hab ich $HOME gleich komplett umbenannt und neu
erstellt: Same result

4.) Schreibe ich "umask 0027" explizit in /etc/profile funktioniert
ebenfalls alles

5.) Ein "strace -f su peter" listet den Aufruf dezidiert aber ich kann
nicht feststellen woher der kommt:

[...]
2622 open("/etc/group", O_RDONLY|O_CLOEXEC) = 4
2622 _llseek(4, 0, [0], SEEK_CUR) = 0
2622 fstat64(4, {st_mode=S_IFREG|0644, st_size19, ...}) = 0
2622 mmap2(NULL, 1719, PROT_READ, MAP_SHARED, 4, 0) = 0xb7786000
2622 _llseek(4, 1719, [1719], SEEK_SET) = 0
2622 fstat64(4, {st_mode=S_IFREG|0644, st_size19, ...}) = 0
2622 munmap(0xb7786000, 1719) = 0
2622 close(4) = 0
2622 socket(PF_FILE, SOCK_STREAM, 0) = 4
2622 connect(4, {sa_family¯_FILE, path="/var/run/nslcd/socket"}, 23) = 0
2622 gettimeofday({1404702848, 321946}, NULL) = 0
2622 gettimeofday({1404702848, 322029}, NULL) = 0
2622 poll([{fd=4, events=POLLOUT}], 1, 10000) = 1 ([{fd=4,
revents=POLLOUT}])
2622 send(4, "\1\0\0\0\212\23\0\0\361\3\0\0", 12, MSG_NOSIGNAL) = 12
2622 gettimeofday({1404702848, 322363}, NULL) = 0
2622 gettimeofday({1404702848, 322464}, NULL) = 0
2622 poll([{fd=4, events=POLLIN}], 1, 60000) = 1 ([{fd=4,
revents=POLLIN|POLLHUP}])
2622 read(4,
"\1\0\0\0\212\23\0\0\0\0\0\0\4\0\0\0baduser\1\0\0\0*\361\3\0\0\2\0\0"..., 1024)
= 57
2622 gettimeofday({1404702848, 323811}, NULL) = 0
2622 gettimeofday({1404702848, 323898}, NULL) = 0
2622 gettimeofday({1404702848, 323983}, NULL) = 0
2622 gettimeofday({1404702848, 324067}, NULL) = 0
2622 gettimeofday({1404702848, 324170}, NULL) = 0
2622 gettimeofday({1404702848, 324256}, NULL) = 0
2622 gettimeofday({1404702848, 324340}, NULL) = 0
2622 gettimeofday({1404702848, 324434}, NULL) = 0
2622 gettimeofday({1404702848, 324518}, NULL) = 0
2622 gettimeofday({1404702848, 324602}, NULL) = 0
2622 gettimeofday({1404702848, 324686}, NULL) = 0
2622 gettimeofday({1404702848, 324772}, NULL) = 0
2622 poll([{fd=4, events=POLLIN}], 1, 0) = 1 ([{fd=4,
revents=POLLIN|POLLHUP}])
2622 read(4, "", 1024) = 0
2622 gettimeofday({1404702848, 325036}, NULL) = 0
2622 close(4) = 0
2622 umask(0777) = 027
2622 umask(07) = 0777
[...]


7.) pam_umask ist natuerlich aktiviert:

# grep -i umask /etc/pam.d/common-session
session optional pam_umask.so usergroups

8.) Das Problem tritt sowohl per SSH Login als auch "su" auf. Der
Benutzer der geht und "peter" kommen beide aus dem LDAP

9.) Benuzter "peter" war in vielen Gruppen (z.B. "floppy" - ein Relikt
von vor 15 Jahren - mein System gibts schon so lang ;-) ). Ich hab alle
relevanten Gruppen entfernt - keine Besserung.


Das System bezieht die Userdaten ueber LDAP mit pam_ldap, libnss ldap
und nslcd. Sehe aber nicht wie das irgendwie die umask aendern koennte.



Also ich glaube derzeit auch an fliegende Elefanten - denn es ist
schlicht unmoeglich unter diesen Vorraussetzungen die umask 007 zu
bekommen. Kann mich jemand auf den Pfad der Realiiaet zurueck holen?

LG
Peter
 

Lesen sie die antworten

#1 Peter J. Holzer
08/07/2014 - 16:08 | Warnen spam
On 2014-07-07 18:27, Peter Mairhofer wrote:
1.) Nur Benutzer "peter" erhaelt die komische umask - andere User und
root wie gewuenscht 027


[...]
5.) Ein "strace -f su peter" listet den Aufruf dezidiert aber ich kann
nicht feststellen woher der kommt:

[...]
2622 open("/etc/group", O_RDONLY|O_CLOEXEC) = 4
2622 _llseek(4, 0, [0], SEEK_CUR) = 0
2622 fstat64(4, {st_mode=S_IFREG|0644, st_size19, ...}) = 0
2622 mmap2(NULL, 1719, PROT_READ, MAP_SHARED, 4, 0) = 0xb7786000
2622 _llseek(4, 1719, [1719], SEEK_SET) = 0
2622 fstat64(4, {st_mode=S_IFREG|0644, st_size19, ...}) = 0
2622 munmap(0xb7786000, 1719) = 0
2622 close(4) = 0
2622 socket(PF_FILE, SOCK_STREAM, 0) = 4
2622 connect(4, {sa_family¯_FILE, path="/var/run/nslcd/socket"}, 23) = 0


^^^^^
nslcd - local LDAP name service daemon.

2622 close(4) = 0
2622 umask(0777) = 027
2622 umask(07) = 0777
[...]



Nachdem die umask gesetzt wird, unmittelbar nachdem der Prozess eine
Antwort von nslcd bekommen hat, liegt da ein Zusammenhang nahe.

Das System bezieht die Userdaten ueber LDAP mit pam_ldap, libnss ldap
und nslcd. Sehe aber nicht wie das irgendwie die umask aendern koennte.



Ich wüsste jetzt auch nicht, dass man in ldap eine Default-Umask
hinterlegen kann (hinterlegen kann man natürlich alles, aber es muss
auch verwendet werden), aber ich würde trotzdem annehmen, dass genau das
der Fall ist.

hp


_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

Ähnliche fragen