Perché i file nella mia home directory vengono creati come scrivibili dal mondo nonostante una umask più restrittiva?

10

Mi sono reso conto che le autorizzazioni per i nuovi file e directory si comportano in modo un po 'strano. Innanzitutto, umask sembra restituire la risposta giusta:

$ umask
0002

Questo significa accesso completo per il mio utente e il mio gruppo, nessun accesso in scrittura per il resto del mondo, nessun aiuto. Ma se creo un file nel mio $ HOME, ecco come appare:

$ ls -l testfile 
-rw-rw-rw- 1 robe robe 0 mar 16 12:58 testfile

vale a dire, dare accesso in scrittura a tutti. Lo stesso succede con le directory:

$ ls -ld testdir
drwxrwxrwx 2 robe robe 6 mar 16 13:00 testdir

Penso che questo sia lo stesso di avere umask 0000, non 0002. Ho cercato in tutti / etc qualche istanza di umask che modifica l'impostazione predefinita 0002 o 0022, ma non ne ho trovata nessuna. Questa è un'installazione predefinita di CentOS 5.5. Qualche idea del perché sta succedendo questo?

centos umask

— rsuarez
fonte

3

Su quale tipo di filesystem è la tua home directory?

— Mattdm,

4

E come stai creando testfilee testdir?

— Mattdm,

3

@mattdm, avevi ragione a insistere: è XFS. Ho dimenticato che abbiamo volumi separati per / home, / var e molti altri. Anche se uso spesso XFS e non ho visto questo comportamento. Come può essere correlato?

— rsuarez,

2

acl può sovrascrivere umask localmente. È possibile che le tue directory vengano montate con acl?

— Faheem Mitha,

3

Hmm, apparentemente xfs ha sempre abilitato acl. quindi potrebbe non essere visualizzato nel tuo / etc / fstab. Prova a eseguire getfacl sulle tue partizioni / directory.

— Faheem Mitha,

3

Non so se sia corretto rispondere alla mia domanda. Redattori, per favore, avvisate questo in caso contrario. Grazie in anticipo.

Penso di aver risolto questo mistero: il problema era la mancanza di un ACL predefinito sui volumi XFS. Ecco la voce ACL per / srv / backups, una delle directory interessate:

# file: srv/backups
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

Ogni volta che ho fatto un "test mkdir" o "touch testfile", mi sono venute le autorizzazioni 777. Quindi ho fatto questo:

setfacl -m d:u::rwx /srv/backups

Lasciando l'ACL in questo modo:

# file: srv/backups
# owner: root
# group: root
user::rwx
group::r-x
other::r-x
default:user::rwx
default:group::r-x
default:other::r-x

In precedenza lì (presumibilmente) non c'era ACL, ma ora c'è. Riesco a vedere il segno "+" associato alle autorizzazioni quando faccio un "ls -l". E magicamente, ora "mkdir test" e "touch testfile" funzionano con le autorizzazioni previste:

# ls -l testfile 
-rw-r--r-- 1 root root 0 Dec 20 10:00 testfile
# ls -ld testdir
drwxr-xr-x+ 2 root root 6 Dec 20 10:00 testdir

Non so perché questo accada. Immagino che a XFS non piaccia non avere un ACL predefinito e si comporta in modo strano quando succede. Inoltre, ho visto che ciò accadeva solo in CentOS, non in Debian / Ubuntu. Forse è correlato alla versione XFS nel kernel o qualcosa del genere. Nessuna idea.

Comunque, questo risolve il caso per me. Grazie mille per tutti i suggerimenti :-)

— rsuarez
fonte

Rispondere alla tua domanda è perfettamente accettabile .

— Keith Thompson,

0

La chiamata del creat può specificare esplicitamente le autorizzazioni che hanno la precedenza su umask.

Non hai risposto a come stai creando testfile,testdir.

Crea il file usando touch testfile, quindi elenca e pubblica le autorizzazioni

— bsd
fonte

Scusa per il ritardo. Ho fatto il test usando "touch testfile", e anche "mkdir testdir", con risultati simili. umask sembra essere impostato su "0000", perché sono stati creati con autorizzazioni 777.

— rsuarez,

0

Prova a getfacl .nella directory in cui stai creando il tuo file di test, per vedere se c'è un acl predefinito che influenza le autorizzazioni.

— Andrea
fonte

1

No, nessun ACL predefinito. Sembra in qualche modo correlato a XFS, perché succede solo nei volumi XFS. Ma grazie comunque.

— rsuarez,

-1

Cerca la variabile USERGROUPS_ENAB su /etc/login.defs

Loro commento per disabilitarlo # USERGROUPS_ENAB sì

Se si desidera modificare anche l'umask dell'utente corrente, è necessario prima seguire la procedura precedente e procedere come segue.

esempio per 027

echo "umask 027" >> ~ / .bashrc && pkill -KILL -u nome_utente_qui

echo "umask 027" >> ~ / .bashrc questo comando imposterà un valore predefinito di umask per il tuo profilo

questo ti costringerà a disconnetterti

dopo il login di nuovo

basta eseguire di nuovo il comando umask e vedere se funziona per te

— user336810
fonte