Forzare il proprietario su file e cartelle creati

Ho una directory che contiene dati condivisi tra un numero di utenti. L'accesso a questa directory e tutto ciò che sta sotto sarà controllato dal gruppo della directory, che verrà aggiunto agli utenti in questione. Come tale ho creato la cartella "gruppo appiccicoso" chmod g+sset. La directory conterrà una struttura ad albero con directory e file, con una quantità totale di file probabilmente di qualche milione. I file saranno abbastanza piccoli, non prevedo nulla di più grande di 50 MB.

Il mio problema è che il proprietario del file o della directory è ancora l'utente che l'ha creato. Pertanto, anche se dovessi rimuovere quell'utente dal gruppo di accesso, non rimuoverei completamente il suo accesso.

Così:

Ci sono altre opzioni che ho perso per garantire che tutti i file e le sottodirectory abbiano lo stesso proprietario?

Mi aspetto di poter navigare periodicamente attraverso l'intera directory con un cron-job, ma ciò mi sembra inefficiente per quello che è essenzialmente un comando once-pr-file.

Ho trovato un esempio usando INotify, ma questo mi sembra molto impegnativo, poiché richiede script.

Non sono stato in grado di capire se ACL può aiutarmi con la proprietà forzata.

C'è un modo più intelligente per farlo?

Quello che voglio è avere una directory che può essere condivisa aggiungendo un gruppo a un utente. Qualsiasi cosa creata in questa directory eredita lo schema di autorizzazione dal suo genitore. Se c'è un modo migliore di quello che sto tentando, sono tutto orecchie.

L'impostazione di un proprietario predefinito "automaticamente" richiederebbe una directory che si setuidcomporta come setgid. Tuttavia, mentre questo può essere configurato su FreeBSD, altri sistemi UNIX e Linux semplicemente ignorano u+s. Nel tuo caso, tuttavia, potrebbe esserci un'altra soluzione.

Quello che voglio è avere una directory che può essere condivisa aggiungendo un gruppo a un utente. Qualsiasi cosa creata in questa directory eredita lo schema di autorizzazione dal suo genitore. Se c'è un modo migliore di quello che sto tentando, sono tutto orecchie.

Quindi, sostanzialmente, da quello che vedo, vuoi controllare l'accesso a una directory usando il meccanismo dei gruppi. Tuttavia, ciò non richiede di limitare le autorizzazioni nell'intera struttura di directory. In realtà, il --xbit di esecuzione della directory potrebbe essere proprio quello di cui hai bisogno. Lasciate che vi faccia un esempio. Supponendo che...

• Il gruppo che controlla l'accesso alla group_dirdirectory è ourgroup.
• Solo le persone del ourgroupgruppo possono accedere group_dir.
• user1e user2appartengono a ourgroup.
• Il umask predefinito è 0022.

... considera la seguente configurazione:

drwxrws---    root:ourgroup   |- group_dir/
drwxr-sr-x    user1:ourgroup  |---- group_dir/user1_submission/
drwxr-sr-x    user2:ourgroup  |---- group_dir/user2_submission/
-rw-r--r--    user2:ourgroup  |-------- group_dir/user2_submission/README

^{Supponiamo che ogni articolo sia stato creato dal suo proprietario.}

Ora, in questa configurazione:

• Tutte le directory possono essere sfogliate liberamente da tutti ourgroup. Chiunque nel gruppo può creare, spostare, eliminare file ovunque all'interno group_dir(ma non in profondità).
• Chiunque non ci ourgroupsarà verrà bloccato group_dire, pertanto, non sarà in grado di manipolare nulla sotto di esso. Ad esempio, user3(che non è un membro di ourgroup), non è in grado di leggere group_dir/user2_submission/README(anche se ha l' r--autorizzazione per il file stesso).

Tuttavia, in questo caso c'è un piccolo problema: a causa della tipica umask, gli elementi creati dagli utenti non possono essere manipolati da altri membri del gruppo. È qui che entrano in gioco gli ACL. Impostando le autorizzazioni predefinite, ti assicurerai che tutto vada bene nonostante il valore umask:

$ setfacl -dRm u::rwX,g::rwX,o::0 group_dir/

Questa chiamata imposta:

• rw(x)Autorizzazioni predefinite per il proprietario.
• rw(x)Autorizzazioni predefinite per il gruppo.
• Nessuna autorizzazione per impostazione predefinita per gli altri. Si noti che poiché gli altri non possono accedere group_dircomunque, non importa davvero quali siano le loro autorizzazioni sottostanti.

Ora, se creo un elemento come user2:

$ touch group_dir/user2_submission/AUTHORS
$ ls -l group_dir/user2_submission/AUTHORS
rw-rw----    user2:ourgroup    group_dir/user2_submission/AUTHORS

Con questo ACL in atto, possiamo provare a ricostruire la nostra struttura precedente:

drwxrws---+    root:ourgroup   |- group_dir/
drwxrws---+    user1:ourgroup  |---- group_dir/user1_submission/
drwxrws---+    user2:ourgroup  |---- group_dir/user2_submission/
-rw-rw----+    user2:ourgroup  |-------- group_dir/user2_submission/README

^{Anche in questo caso, ogni articolo viene creato dal suo proprietario.}

Inoltre, se desideri dare un po 'più di potenza / sicurezza a coloro che usano la directory, potresti considerare un po' appiccicoso. Ciò, ad esempio, impedirebbe l' user1eliminazione user2_submission(poiché dispone -w-dell'autorizzazione group_dir):

$ chmod +t group_dir/

Ora, se user1prova a rimuovere user2la directory, otterrà un risultato adorabile Operation not permitted. Si noti tuttavia che mentre ciò impedisce le modifiche alla struttura delle directory in group_dir, i file e le directory sottostanti sono ancora accessibili:

user1@host $ rm -r user2_submission
Operation not permitted

user1@host $ cat /dev/null > user2_submission/README

user1@host $ file user2_submission/README
user2_submission/README: empty (uh-oh)

Un'altra cosa da tenere in considerazione è che gli ACL che abbiamo usato impostano le autorizzazioni predefinite . È quindi possibile per il proprietario di un articolo modificare le autorizzazioni ad esso associate. Ad esempio, user2può funzionare perfettamente ...

$ chown g= user2_submission/ -R
or
$ chgrp nobody user2_submission -R

... quindi rendendo la sua directory di presentazione completa non disponibile per chiunque nel gruppo.

Tuttavia, poiché in origine sei disposto a dare pieno rwsaccesso a chiunque nel gruppo, suppongo che ti fidi di questi utenti e che non ti aspetteresti troppe operazioni dannose da loro.

C'è un modo più intelligente per farlo. Usa una combinazione di set-gid e acls predefiniti . Ovviamente, avrai bisogno di un file system abilitato per acl. Supponiamo che la directory che desideri sia condivisa /var/grpdire che i membri del gruppo sharingsiano in grado di accedervi.

chown root:sharing /var/grpdir
chmod 2770 /var/grpdir #other can't read or traverse into the directory, set-gid is set
setfacl -d -m u::rwX,g::rwX,o::0 /var/grpdir

Gli ACL predefiniti sono ereditati da sottodirectory create in una directory con ACL predefiniti. Quindi questo significa che per ogni file creato /var/grpdirverrà impostato il gruppo sharingdal bit setgid della directory. Inoltre, erediterà gli acls predefiniti, che sostituiranno le premesse di stile linux predefinite, perché non abbiamo specificato ACL con utenti o gruppi specifici. Ciò significa che tutti i file verranno creati con proprietà <user>:sharinge autorizzazioni rw-rw----. Le directory saranno le stesse, tranne per il fatto che avranno i propri ACL predefiniti impostati sullo stesso del loro parent ( /var/grpdir) e, naturalmente, i bit eseguibili impostati per utente e gruppo. Se rimuovi un utente dal sharinggruppo, non sarà in grado di accedere alla directory (né a tutti i file in essa contenuti, anche se li possiede).

A differenza della correzione periodica delle autorizzazioni con un cronjob, le autorizzazioni sono sempre sincronizzate, poiché vengono aggiornate atomicamente con i file e le directory appena creati. Questa soluzione è leggera; non sono necessari demoni e non vi è alcun picco di IO mentre si correggono le autorizzazioni in un colpo solo.

Non sono a conoscenza di alcun buon modo per farlo. Il modo tecnicamente più pulito sarebbe un file system FUSE che lo fa. Certo, molto lavoro se nessuno lo ha ancora fatto.

alternative:

1. Usa la samba. samba ha il force userparametro È possibile esportare una directory localmente e montarla localmente. Non rende gli accessi più veloci ma può essere accettabile poiché è coinvolta solo la rete di loopback.

2. Utilizzare un file system non Linux come FAT32. Questo deve essere configurato per un determinato utente per montarlo. Le autorizzazioni di accesso devono essere gestite dalla directory principale.

Non ho sentito alcun modo per modificare automaticamente la proprietà di un file in modo tale che il proprietario del file venga modificato quando il file viene spostato in una determinata directory. La cosa più vicina è la parte appiccicosa, ma sembra che tu abbia indicato che la proprietà del gruppo non è sufficiente, la proprietà dell'utente reale deve cambiare.

In quel caso, penso che la tua scommessa migliore sia il cron job con la bandiera chown -R, come ha detto Pandya. Mettilo su un cron per eseguire ogni minuto o ogni cinque minuti.

Se puoi spiegare come i tuoi utenti lo stanno usando, potrebbe esserci una soluzione migliore.

ACL può aiutarti a ottenere un controllo più preciso del grano su chi è autorizzato a fare cosa, non cambierà automaticamente la proprietà effettiva del file per te. Penso che sia necessario ottenere una visione più elevata e valutare / riprogettare la soluzione su tale base.

Puoi usare inotify-tools e scrivere un semplice script bash come di seguito. Inotify terrà d'occhio la directory web e farà qualcosa ogni volta che si verificherà un evento come la creazione di dir all'interno della directory web. Ci sono molti eventi esistenti. Puoi cercarlo su Google o potrebbe aver consultato questo sito

while inotifywait -m -e CREATE web; do echo "A new directory has been created"; done