Posso trasferire le autorizzazioni utente su tutti i computer per un disco rigido esterno ext4?

16

Ho un'unità disco USB 3 esterna (capacità 2 TB) che molto probabilmente verrà spostata da una macchina all'altra. Il disco ha una tabella delle partizioni GUID e una partizione ext4. Non riesco a scrivere sul disco se non elevo il processo ( sudo).

A partire da ora sto pensando di provare uno o entrambi i seguenti e vorrei conoscere i contro di ciascuno -

chmod 777 /mnt/externalDrive
chown nobody:nogroup /mnt/externalDrive

Se autorizzo 777 e l'utente1 (UID: 1005) scrive su di esso e in seguito trasferisco il disco su un altro computer in cui user7 è UID: 1005, cosa succede? User7 diventa il proprietario del file su quel computer? Mi sembra che dovrò periodicamente correre chown -R nobody:nogroup /mnt/externalDrivesul disco.

Qualcosa di ciò che sto prendendo in considerazione è un'ovvia cattiva pratica? Molto probabilmente il disco conterrà video, musica e immagini che non devono essere protetti come alcuni dati finanziari.

permissions ext4 external-hdd

— Lord Loh.
fonte

Non sono sicuro di seguirti. Hai provato a impostare le autorizzazioni nell'unità esterna?

— Ramesh,

1

Sì. Questa è una buona cosa?

— Lord Loh.

19

Questo è il problema con i sistemi multiutente, soprattutto se ne hai più di uno. ;) Non c'è davvero un bel modo di fare quello che vuoi. Gli approcci che verranno in mente sarebbero

avere lo stesso UID per il tuo account su ogni macchina che stai utilizzando il tuo disco esterno (in realtà non è fattibile, poiché molto probabilmente non tutte le macchine sono sotto il tuo controllo)
usando un file system ignaro del concetto di proprietario / gruppo (mi viene in mente FAT o NTFS, ma ... aaah, no)

L'approccio più efficace sarebbe tornare alle pratiche comuni. Sulla maggior parte (almeno) dei sistemi Linux, esistono alcuni gruppi che hanno solitamente GID comuni. Ad esempio sarebbe users, che ha GID 100sulla maggior parte delle distro Linux. Se riuscissi ad avere il tuo rispettivo account utente in questo gruppo, potresti

rendere tutti i file e le directory sul disco di proprietà di questo gruppo
in qualche modo riesce ad avere le autorizzazioni di gruppo appropriate su quei file e directory
in qualche modo riescono a creare nuovi file con rispettiva proprietà del gruppo. permessi.

Il primo e il secondo punto sono facili da realizzare ( chown, chmod). Il terzo punto diventa un po 'più complicato.

La parte "proprietà del gruppo" è relativamente semplice: è possibile impostare il bit SGID su tutte le directory sul disco. Il bit SGID applicato alle directory dice al kernel di comportarsi in modo BSDish: BSD rende ogni file / directory creato in uno specifico gruppo di directory di proprietà del gruppo primario del processo creando il file / directory (come fa Linux), ma dal proprietario della directory principale.

Il bit di autorizzazione è un po 'difficile. Le autorizzazioni per i file / le directory appena creati sono (tra gli altri) influenzate da umaskuna maschera di bit che indica quali bit non impostare se non esplicitamente indicati. Un umaskvalore comune , ad esempio 022, è che significa che i bit di scrittura per »gruppo« e »altri« di solito non dovrebbero essere impostati. Puoi cambiarlo umaskin 002, dicendo che non vuoi che le autorizzazioni di scrittura vengano cancellate per il gruppo, ma il rovescio della medaglia è che non puoi impostare questo valore in base alla directory e di solito non vuoi avere le autorizzazioni di scrittura per il tuo gruppo principale impostato per ogni file che crei.

Questo potrebbe essere risolto utilizzando le ACL: In un'ACL è possibile impostare una maske un defaultset di autorizzazioni, che si applica a tutti i file e le directory creati all'interno di una directory con questo set ACL. Quindi una possibile soluzione del tuo problema sarebbe

assicurandoti di essere un membro di un gruppo comune su tutti i sistemi su cui desideri utilizzare l'unità esterna
rendere tutti i file e le directory sul disco di proprietà di questo gruppo e impostare il bit SGID su tutte le directory
cambia l'ACL di tutte le directory per includere una maschera e le autorizzazioni predefinite che indicano al kernel di creare ogni nuovo file / directory con le autorizzazioni di scrittura impostate per il gruppo.

Vedi setfacl(1), e acl(5)per maggiori dettagli.

— Andreas Wiese
fonte

1

C'era una patch fluttuante per la sua e gid mapping in ext4, spinics.net/lists/linux-fsdevel/msg57240.html , ma non credo che sia passato ...

— Rmano

11

C'è un'altra domanda simile e bindfs è suggerito lì:

mkdir /home/$user/sda1
bindfs -u $user -g $group /mnt/sda1 /home/$user/sda1

Gli utenti OSX suggeriscono l' noownersopzione di montaggio descritta in questo modo:

Ignora il campo di proprietà per l'intero volume. Ciò fa apparire tutti gli oggetti come appartenenti all'ID utente 99 e all'ID gruppo 99. L'ID utente 99 viene interpretato come l'ID utente effettivo corrente, mentre l'ID gruppo 99 viene utilizzato direttamente e tradotto in `` sconosciuto ''.

— Michael Shigorin
fonte

bindfs è piuttosto lento. Probabilmente perché è un filesystem FUSE.

— Navin,

4

Il proprietario e il gruppo di un file sono memorizzati come numeri. Quindi il file sarà di proprietà di uid = 1005, indipendentemente da quale utente (o nessuno) sia sul sistema a cui è connesso.

La modifica dell'utente / del gruppo in nessuno non risolverà il problema. Quindi solo l'utente utente (o i membri del gruppo nobody) potrebbero accedere ai file.

Sfortunatamente, non penso che ci sia un modo per disabilitare i controlli delle autorizzazioni su ext4. Vedi, ad esempio, è possibile disabilitare i permessi dei file su un file system ext3 o ext4?

— derobert
fonte

2

Andreas Wiese afferma che se si dispone di un ID di gruppo comune su tutti gli host, è possibile risolvere il problema con setgidbit e ACL

Pongo domande ID di gruppo predefiniti nelle distro Linux?

Dopo una propria ricerca, è emerso che tale gruppo esiste in tutte le distro toccate: sysID di condivisione di gruppo 3su Debian, Ubuntu, RedHat, Fedora, CentOS, Suse, FreeBSD, OpenBSD, NetBSD, MacOSX, Solaris.

Con questo:

$ sudo chgrp -R sys /mnt/data/dir
$ sudo chmod -R g+s /mnt/data/dir
$ sudo setfacl -R -m g:sys:rwx /mnt/data/dir
$ sudo setfacl -R -d -m g:sys:rwx /mnt/data/dir

e sapore di questo:

$ sudo adduser user sys

puoi userleggere / scrivere qualsiasi file su /dir.

La maggior parte dei lavori può fare qualcosa, setgidma sfortunatamente di solito hai poco controllo umask. Quindi ACL viene utilizzato per fornire una soluzione completa.

Guarda anche:

— gavenkoa
fonte