Leggi i file di proprietà di un altro utente come non root


9

Sto eseguendo il backup dei server su un server di backup. Ogni server di cui è stato eseguito il backup ha il proprio account sul server di backup e i file vengono sincronizzati nuovamente. È importante che le autorizzazioni rimangano intatte (usando rsync -p) per semplificare i ripristini.

Sto cercando di creare uno script in grado di leggere i file e creare alcune statistiche. Non mi piace che quello script sia eseguito sotto l'utente root, ed è anche impossibile eseguirlo per ogni utente di backup, poiché lo script dovrebbe essere in grado di leggere tutti i file da tutti gli utenti. Tuttavia, ciò crea un problema quando, ad esempio, un file viene scambiato con 600. Non voglio toccare le autorizzazioni, ma un altro utente tranne root e il proprietario non possono leggerlo.

Un utente specifico, non root, dovrebbe essere in grado di leggere tutti i file in una directory o partizione, indipendentemente dai livelli di autorizzazione (e il proprietario dei file non dovrebbe avere modo di impedirlo). C'è un modo per raggiungere questo obiettivo? Sto eseguendo FreeBSD con un volume ZFS.


Questa è stata la mia prima domanda in questo sito :) Probabilmente puoi dare un'occhiata anche a questo. unix.stackexchange.com/questions/91488/…
Ramesh,

Risposte:


4

Usa sudo.

Se il tuo sudoersfile elenca un comando esatto e specifico, il comando deve essere chiamato esattamente come elencato in sudoersoppure verrà negato.

Per esempio:

backupuser  ALL=(root) /usr/bin/rsync -aH /files/to/backup/ /copy/of/backup/

In questo esempio l'utente backuppuò eseguire il comando esattamente come mostrato:

sudo /usr/bin/rsync -aH /files/to/backup/ /copy/of/backup/

Se chiamano sudo rsync...invece del sudo /usr/bin/rsynccomando non riesce, o se i flag o i percorsi sono diversi, il comando fallisce.

Se lo stai facendo in uno script, vuoi abilitare l'uso senza password di questi comandi:

backupuser  ALL=(root) NOPASSWD: /usr/bin/rsync -aH /files/to/backup/ /copy/of/backup/

Per di più vedi la sudoers(5)pagina man sotto Cmnd_list.


Grande idea. Ho aggiunto i comandi ls, cat, head, tail etc. al file sudoers e ora posso eseguirli con i privilegi di root e leggere tutti i file. Potrebbe non essere la soluzione migliore per tutti, in quanto l'utente è in grado di leggere tutti i file sul sistema, ma questo non è un problema nella mia configurazione.
Evianon,

Bene, se steste usando Solaris avrei suggerito RBAC e pfexec. Ma dato che sei su BSD, sudodovrai farlo.
bahamat,

4

È possibile scrivere una suidversione cateseguibile solo dall'utente di backup (rendere un gruppo esclusivo per l'utente di backup e rendere l'eseguibile leggibile solo da quel gruppo). Ciò catti consentirebbe solo di leggere i file nella directory che ti interessa. (Probabilmente vorresti disabilitare i collegamenti simbolici e fare attenzione a trucchi come /dir/../otherdir/.)

Quindi il tuo script può usare questo eseguibile per leggere i file senza avere i privilegi di root.


4

ATTENZIONE: Come ha sottolineato Stephane nei commenti qui sotto, i proprietari dei file saranno comunque in grado di revocare l'ACL.

Se si dispone dell'accesso root alla macchina, è possibile farlo con ACL :

setfacl -R -m u:USERNAME:r /path/to/direcory

Questo darà USERNAMEaccesso in lettura a tutti i file e le directory in /path/to/directory.


I proprietari dei file sarebbero comunque in grado di rimuovere tali ACL.
Stéphane Chazelas,

@StephaneChazelas oh. Anche se questo è stato fatto da root? Non me ne sono reso conto. Conosci un modo per aggirarlo?
terdon

No, su Linux avrei esaminato una combinazione di funzionalità Linux e LSM. Su FreeBSD non ne ho idea.
Stéphane Chazelas,

1

Bindfs è un file system FUSE che fornisce visualizzazioni di un albero di directory con autorizzazioni e proprietà diverse. Non c'è porta per FreeBSD, ma puoi compilare dal sorgente.

Per dare all'utente backupper(e solo a quell'utente) una vista di /some/filesdove tutti i file sono leggibili, montare una vista leggibile in tutto il mondo /some/filesin una directory privata di backupper.

mkdir -p ~backupper/spyglass/files
chown backupper ~backupper/spyglass
chmod 700 ~backupper/spyglass
bindfs -p a+rX-w /some/files ~backupper/spyglass/files

0

ZFS ha alcuni meccanismi per questo.

Uno dei meccanismi è ancora in lavorazione e non ancora implementato, ma consente di montare un set di dati con una sostituzione "proprietario". In questo caso, è possibile clonare un'istantanea, montarla con il proprietario sovrascritto all'utente di backup, eseguirne il backup, quindi distruggere il clone. il rovescio della medaglia è che non si esegue il backup della proprietà reale dei file.

La migliore soluzione è probabilmente gli ACL in stile nfsv4 di ZFS


0

Ho due idee su come risolvere questo problema usando le tecnologie specifiche di FreeBSD, anche se non ho provato neanche:

  • Usa il Capsico. Questo è il mio metodo preferito. Inoltre, poiché è stato recentemente portato su Linux, dovrebbe funzionare anche lì. Andrebbe così:

    1. Creare un comando drop-cap-write che elimina CAP_WRITE quindi esegue un comando fornito sulla riga comandi
    2. Utilizzare sudo per consentire all'utente di backup di eseguire quel comando senza password
    3. Facoltativamente, utilizzare la direttiva ForceCommand di sshd_config per eseguire automaticamente quel comando ogni volta che l'utente di backup accede. In questo modo, l'utente remoto non dovrebbe specificare drop-cap-write nel suo script di backup.
  • Utilizzare il controllo di accesso obbligatorio. Questo non funziona su Linux AFAIK ed è più complicato da configurare. Andrebbe così:

    1. Crea una jail di backup il cui rootdir è /. Hard-code il jailid.
    2. eseguire sshd nella jail di backup. Consenti al root di effettuare il login qui, anche se non consenti i login root nel normale sshd
    3. Impostare ugidfw_enable = "YES" in /etc/rc.conf
    4. Usa una regola ugidfw simile a questa:

    ugidfw aggiungi soggetto uid root jailid BACKUP_JAIL_ID modalità rsx

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.