PDA

View Full Version : Problema settaggio privilegi


Nuitari
29-09-2004, 15:41
Buongiorgio a tutti =) E' diverso tempo che non ci si vede eh?

Ho un piccolo problemino con i settaggi dei privilegi su Linux... è presto detto.

Su uno dei miei server ho configurato CVS in modo che agisca da server (metodo di autenticazone pserver, so che non è figo come rsh ma per il momento passatemelo).

I client accedono al repository con la propria utenza principale Linux (distribuita con NIS, so che non è figo come LDAP ma per il momento passatemelo :D ) a patto che appartengano al gruppo "cvs", il gruppo che detiene i privilegi della root del repository (/var/cvsroot).

Il problema è che quando fanno il commit delle modifiche, il gruppo propietario dei file cambia con il gruppo PRIMARIO dell'utente che effettua il commit, non con il gruppo "cvs", di cui fa parte, anche se è solo grazie al fatto che appartengono a quel gruppo che hanno il privilegio di poter accedere al repository.

es.:


root@melkor:~/timesheet# ls -ld /var/cvsroot
drwxrwxr-x 4 root cvs 104 2004-09-22 16:15 /var/cvsroot
root@melkor:~/timesheet# ls -l /var/cvsroot/
total 3
drwxrwxr-x 3 root root 1112 2004-07-21 21:56 CVSROOT
drwxrwxr-x 21 root cvs 656 2004-09-29 18:49 timesheet
root@melkor:~/timesheet# touch prova.txt
root@melkor:~/timesheet# cvs add prova.txt
cvs add: scheduling file `prova.txt' for addition
cvs add: use 'cvs commit' to add this file permanently
root@melkor:~/timesheet# cvs commit -m "prova" prova.txt
RCS file: /var/cvsroot/timesheet/prova.txt,v
done
Checking in prova.txt;
/var/cvsroot/timesheet/prova.txt,v <-- prova.txt
initial revision: 1.1
done
root@melkor:~/timesheet# ls -l /var/cvsroot/timesheet/ | grep prova
-r--r--r-- 1 nuitari bo 444 2004-09-29 18:53 prova.txt,v


Oltrettutto viene impostato l'attributo di "read" su "others" e non mi va, vorrei limitarlo al gruppo...

Che Linux funzioni in questo modo oramai l'ho capito. La mia domanda è: come posso costringere il "sistema" a creare i file con il gruppo che voglio io in quella particolare directory, indipendentemente dal gruppo primario dell'utente che effettua la modifica?

L'unica cosa che mi viene in mente è di utilizzare un mount samba al posto della cartella fisica, potendo così beneficiare dei parametri "force", ma mi piacerebbe sapere se esiste un altro metodo a livello di *sistema* che non implica l'utilizzo di Samba.

Ho provato anche a replicare le utenze nel file passwd (di CVS) impostando come alias dell'utente uno creato ad hoc (cvspub) che abbia come gruppo primario il gruppo cvs. Indipendentemente dall'utenza utilizzata dai vari utenti i file vengono modificati con quel nome utente e con il suo gruppo primario... solo che così devo in pratica re-sincronizzare i file ogni volta che avviene una modifica all'utenza, con il nuovo hash, cosa che vorrei evitare. Inoltre così non ho il controllo sull'attributo di read.

Qualche idea? :D

Tilion
29-09-2004, 16:17
http://www.salleurl.edu/~is04069/Codders/cvspasoapaso.html

in particolare come descritto in "Create a repository" devi settare umask dell'utente e group sticky.

occhio che normalmente ho sempre trovato più comodo mappare tutte le utenze cvs ad una singola utenza cvs, tenere file sul repository con permessi diversi è utile solo se devi gestire i permessi fra i developer che accedono a cvs (tipo se vuoi che qualcun'altro non acceda ai tuoi sorgenti o viceversa)

Nuitari
30-09-2004, 20:01
Uhm visto, ma non mi pare che risolva il mio problema... forse e dico forse solo quello degli attributi, ma non quello del gruppo, dato che nello stesso repository memorizzo informazioni differenti che devono essere accessibili a gruppi differenti.

Comunque, quello del CVS era un esempio. Ho la necessità anche in altri ambiti (es.: automount delle home in remoto) che i nuovi file o cmq quelli modificati abbiano un gruppo d'utenza e dei privilegi "forzati" in base alla directory, e per il momento l'unica ipotesi valida m'è parsa quella di creare un mount ad hoc con samba. Ma in realtà è inadeguato anche questo, perchè non posso influenzare le subdir ma l'intero tree..

Tilion
30-09-2004, 20:23
forse non ho capito bene allora cosa devi fare :scratch:

repository /cvs
users di linux: wourkgroup1 wourkgroup2
users di cvs: pippo pluto paperino gastone

il server impersonifica l'utente di login salvo che non sia specificato nel passwd di cvs (che è /cvs/CVSROOT/passwd) di impersonificare un altro utente che però sarà sempre censito in linux.

avrai un file passwd di cvs tipo:
pippo:<pass1>:workgroup1
pluto:<pass2>:workgroup2
paperino:<pass3>:workgroup1
gastone:<pass4>:workgroup2

a questo punto con una umask 002 (penso :look:) avrai nel repository file fisicamente leggibili solo dagli utenti workgroup1 e workgroup2 ma non tramite cvs dove pippo potrà leggere i file di paperino ma non quelli di pluto o gastone.

tieni presente che:
1. con questo sistema non puoi gestire che pluto possa leggere i file di pippo ma non scriverli... (o meglio sì ma è da approfondire)
2. cvs può ignorare le utenze di sistema ed in ogni caso se non ricordo male /cvs/CVSROOT/passwd ha precedenza
3. il censimento di utenze su cvs necessita un lavoro aggiuntivo rispetto alla semplice apparteneza al gruppo cvs
4. beh meglio ssh che rsh ;)

piuttosto che un mount in loopback di una directory puoi anche valutare di mettere uno script post-commit che cambi gli attributi dei file appena committati

edit: se devi solo settare il gruppo dei file committati a cvs allora molto probabilmente te la cavi aggiungendo una riga al file /cvs/CVSROOT/loginfo


# The "loginfo" file controls where "cvs commit" log information
# is sent. The first entry on a line is a regular expression which must match
# the directory that the change is being made to, relative to the
# $CVSROOT. If a match is found, then the remainder of the line is a filter
# program that should expect log information on its standard input.
#
# If the repository name does not match any of the regular expressions in this
# file, the "DEFAULT" line is used, if it is specified.
#
# If the name ALL appears as a regular expression it is always used
# in addition to the first matching regex or DEFAULT.
#
# You may specify a format string as part of the
# filter. The string is composed of a `%' followed
# by a single format character, or followed by a set of format
# characters surrounded by `{' and `}' as separators. The format
# characters are:
#
# s = file name
# V = old version number (pre-checkin)
# v = new version number (post-checkin)
# t = tag or branch name
#
# For example:
#DEFAULT (echo ""; id; echo %s; date; cat) >> $CVSROOT/CVSROOT/commitlog
# or
#DEFAULT (echo ""; id; echo %{sVv}; date; cat) >> $CVSROOT/CVSROOT/commitlog

ALL /bin/chown :cvs {s}


(o molto probabilmente cercando di ricostruire il nome del file rcs con uno script ^^' )

Nuitari
08-10-2004, 13:51
Eheheh no pare che non mi son spiegato bene.

Io ho bisogno, a prescindere da CVS, di "forzare" i privilegi e gli attributi dei file creati in determinate directory. Quello di CVS era un esempio, pratico, ma pur sempre un esempio, "purtroppo" ho questa necessità anche in altri ambiti (NFS, etc).

Facciamo un esempio pratico che prescinde da CVS.

In un ipotetica società "mycorp" ho 3 ipotetici utenti, "tizio" "caio" e "sempronio".

"tizio" è uno sviluppatore, "caio" è un sistemista e "sempronio" è sia un sistemista che uno sviluppatore.
Quindi, organizzo logicamente gli utenti in modo che facciano TUTTI parte di un gruppo primario "mycorp" ED ANCHE parte dei gruppi secondari "assistenza" e "sviluppo".

Da questo ecco rispettivamente il mio file passwd semplificato:

tizio:x:1000:500
caio:x:1001:500
sempronio:x:1002:500

ed il mio file group:

mycorp:x:500:
sviluppo:x:501:tizio,sempronio
assistenza:x:502:caio,sempronio

Stabilito ciò, veniamo al dunque: nella directory home del server, oltre alle rispettive homedirs, creo 3 directory che fungano da banale filesharing sia per l'intera società che per i rispettivi reparti, quindi avrò:

drw-rw---- mycorpadmin mycorp pub
drw-rw---- mycorpadmin sviluppo pub_sviluppo
drw-rw---- mycorpadmin assistenza pub_assistenza

All'interno della directory pub, tutto vive felice e tranquillo: qualsiasi file modificato o creato da uno qualsiasi degli utenti avrà come proprietaro l'utente e come gruppo mycorp, considerato che mycorp è il gruppo primario di ogni utente.

I problemi sorgono all'interno, ad esempio, della directory pub_assistenza.
Supponiamo che al suo interno esista un file che si chiama "lista_spesa.sxw". Apparirà nel seguente modo:

-rw-rw---- mycorpadmin assistenza lista_spesa.sxw

Come è evidente, caio e sempronio potranno leggere e scrivere il file, tizio no, e tutto questo è bello e funziona.
Nel momento però in cui uno dei due dovesse modificare il file (caio ad esempio), i privilegi cambierebbero nel modo seguente:

-rw-rw---- caio mycorp lista_spesa.sxw

questo perchè linux mi imposta di default come gruppo del file modificato (o creato) il gruppo primario dell'utente che ha effettuato la modifica. Così però tutto il modello di sicurezza viene a cadere, perchè una volta che conosce l'esistenza del file, anche tizio potrà leggerlo e scriverlo, immettendo il suo percorso completo, e questo anche se la cartella principale pub_assistenza gli è negata.

Quindi, rieccoci al mio problema: come faccio a far si che i file (e le directory, ovviamente) creati dentro la directory "pub_assistenza" abbiano SEMPRE e comunque impostato come gruppo "assistenza"?
Sono sicuro che c'è un modo semplice di farlo con qualche settaggio del cavolo, o addirittura un flag sui file, solo che non so qual'è, molto banalmente :) E man e google non mi hanno aiutato

Edit:

Ho sistemato un po' i nomi dei file :p

Tilion
08-10-2004, 17:34
ok ora è molto più chiaro :D
cmq il file cambia owner e gruppo perchè viene cancellato e riscritto e nel particolare con programmi di office:

- move orig -> temp
- save new
- delete temp

a questo punto effettivamente linux piazza gli attributi dell'autore e questo è normale a meno che non setti uno sticky sulla directory, in particolare (ho appena provato) lo sticky sull'utente non funzia ma sul gruppo (che è quello che ti interessa) sì.


# cd /
# mkdir prova
# chmod 777 prova
# ll . | grep prova
drwxrwxrwx 2 root root 4096 Oct 8 18:23 prova
# echo root > prova/root
# ll prova
-rw-r--r-- 1 root root 5 Oct 8 18:22 root
# chmod g+s prova
# ll . | grep prova
drwxrwsrwx 2 root root 4096 Oct 8 18:23 prova
# su - oracle
$ echo oracle > /prova/oracle
$ logout
# ll prova
-rw-r--r-- 1 oracle root 7 Oct 8 18:23 oracle
-rw-r--r-- 1 root root 5 Oct 8 18:22 root
# chmod g-s prova
# ll . | grep prova
drwxrwxrwx 2 root root 4096 Oct 8 18:23 prova
# su - oracle
$ echo oracle > /prova/oracle2
$ logout
# ll prova
-rw-r--r-- 1 oracle root 7 Oct 8 18:23 oracle
-rw-r--r-- 1 oracle oracle 7 Oct 8 18:23 oracle2
-rw-r--r-- 1 root root 5 Oct 8 18:22 root


il file "oracle" è stato creato con il gruppo dell directory dove risiede quindi nel tuo esempio tutti i file nella directory "assistenza" rimarrebbero del gruppo "assistenza" ma cambierebbeo l'utente (cosa plausibile e che permette di verificare chi fà cosa in qualche modo).
Non penso sia invece possibile settare il gruppo in base all'utenza se non per il gruppo primario perchè non è disponibile il contesto della creazione (non sò se l'utente sempronio è in veci di sviluppatore o assistente).
beh.. perlomeno il gruppo ora è ok :awk:

Nuitari
08-10-2004, 18:05
appunto, era un flag del cazzo ^_^

Quindi l'attributo sgid impostato su una directory costringe i file ivi contenuti ad ereditare il suo gruppo, pare.
Avevo frainteso completamente il suo utilizzo, o forse l'avevo limitato ad utilizzi specifici.

A me cmq serve proprio settare il gruppo in base alla directory, quindi è perfetto così.
Ammetterai che anche in un ottica di CVS, usare lo sgid per fissare il gruppo invece di mappare tutti gli utenti nel file passwd di CVS ha il suo grosso vantaggio: non sei costretto a replicare e sincronizzare le password manualmente.

Che dire, grazie 1000 ! ^__^

PS.: un unico appunto: lo sticky è il flag t :)
Un altra cosa: ma l'umask non è un settaggio a livello di utente (una variabile di shell)? Come faccio a settare un umask specifica per una directory indipendentemente dall'utenza?

Tilion
09-10-2004, 00:33
il flag da usare + s non t,

set user or group ID on execution (s): se applicato ad eseguibili l'eseguibile viene lanciato con l'utente e/o il gruppo di appartenenza del file indipendentemente da chi lo lancia (ad esempio è possibile lanciare xmms supponendo che sia stabile e no risk per tutti gli utenti anche se non hanno accesso al gruppo audio), mentre se applicato alle directory fà ereditare gruppo (user non mi è parso) ai file creati all'interno.

sticky (t): propaga le ownership ai figli (gli attributi sono dati dalla umask), è il flag che c'è in /tmp per far sì che anche le cartelle create ereditino il comportamento del parent (non ho provato ma in effetti forse tu avrai bisogno sia di s che t.

l'umask è un comando non standard che serve per settare un default per i file creati in una determinata directory peccato che sia una chiamata che deve fare il processo che crea il file e non penso che si possa ereditare fra processi :P
bash supporta umask tramite comando interno, non è una variabile semplicemente un alias per fare una chiamata all'ioctl dal processo della shell (man umask lo spiega un po' meglio ^^)

per cvs ho sempre tenuto separato gli acct di sistema da quelli utente giusto perchè non volevo che chi aveva accesso a cvs avesse accesso anche ad una shell, è possibile bloccare i login anche con shell /bin/false o /sbin/nologin ma se non c'è proprio la riga in passwd mi sento più tranquillo :D (e cmq se non devono avere shell mi pare anche più elegante)

Nuitari
09-10-2004, 08:04
Eheh non hai capito. So qual'è la differenza fra lo sticky e lo sgid. Ti ho detto che lo sticky è il flag t perchè tu avevi chiamato lo sgid sticy nel reply precedente, cmq pace.

Riassumendo, in pratica non posso impostare l'umask per una determinata cartella indipendentemente dall'utente, sono quasi al punto di partenza.
A conti fatti l'unico modo che ho per avere il controllo totale sui file è tramite un mount samba, anche se è cmq limitato pure lui... una bella fregatura. Eppure un modo dev'esserci =)

Tilion
14-10-2004, 09:31
ok ho fatto casino come al solito con i termni ma non ho capito neanche se hai risolto oppure no :awk:
penso sia possibile settare l'umask al momento del mount con il parametro:

mount -o bind,umask=0647 /var/real /var/umasked

umask è impostabile per i volumi vfat, non ho mai provato per dei bind o su altri filesystem :P
non sò quanto sia comodo al limite fare un loopback su file in formato vfat ma al limite potrebbe essere preferibile usare nfs piuttosto che samba.

Nuitari
15-10-2004, 09:56
Mi son reso conto che l'umask non basta =)
Ciò di cui ho bisogno è di un force sui privilegi, directory per directory.

Ti spiego: seguendo l'esempio precente, nella dir pubblica di un gruppo i file dovrebbero SEMPRE essere leggibili (e scrivibili) da un gruppo, quindi dovrei avere a disposizione un metodo che mi garantisca che i file creati in una dir abbiano sempre i flag appropriati settati.

L'umask non mi garantisce questo, semplicemente mi garantisce che non siano settati privilegi che io non voglio siano settati, dato che agisce "al contrario".

Inoltre, fare il mount di ogni singola directory che voglio controllare mi sembra improponibile..

Alla fine l'unico che si avvicina a queste funzionalità è samba, temo, ma anche in questo caso fare uno share per ogni directory da controllare non è pratico.

Tilion
15-10-2004, 12:34
non le ho mai provate ma forse con le acl posix si può far qualcosa

Nuitari
15-10-2004, 16:22
Temevo che l'avresti detto :D Alla fine le acl sono una delle cose che dovevo guardare (non posso pensare di mettere in piedi un server di dominio NT che non le supporti) ma che ho sempre rimandato per mancanza di tempo.. mi rendo conto per* che purtroppo oggi mi trovo a perdere tempo per risettare privilegi sballati per via della mancanza d'un controllo del tipo descritto. Vabbeh, mi cimento e ti dico :D
Una domanda: le acl posix sono le acl che distribuiscono con il kernel, in teoria, e non dipendono dal filesystem, giusto? O ti riferisci ad un implementazione particolare su un filesystem particolare?

Tilion
17-10-2004, 00:38
Originally posted by Nuitari
Una domanda: le acl posix sono le acl che distribuiscono con il kernel, in teoria, e non dipendono dal filesystem, giusto? O ti riferisci ad un implementazione particolare su un filesystem particolare?

sò per certo che sono supportate su ext3 e penso anche in ext2, si basano su un sistema di gestione di attributi arbitrari (non standard) sul filesystem, cosa prevista dalla maggioranza dei fs in circolazione.
non sò dirti se sia necessario un kernel 2.6 (che però aveva problemi con l'usb e tutt'ora con certi raid) o le stesse patch ci siano anche per 2.4 ma con un "make menuconfig" dovresti accorgertene subito ;)
di sicuro ti serviranno delle utilities userspace per importarle .

Nuitari
19-10-2004, 10:42
Si ho capito cosa intendi. Ci sono anche per reiserfs. Con i kernel 2.4 devi patchare a manina per il filesystem desiderato, con il 2.6 ce l'hai builtin.
Da quel che ne so vengono sfruttati i metadati dei filez, cmq appena provo ti dirò =)