nieuw bestand rechten laten overnemen van bovenliggende map

[makje]

Ik heb hier een test Linux terminalserver met daarop verschillende testgebruikers.
De gebruikers zitten in een paar verschillende gebruikersgroepen.

Op de server is een gezamenlijke documentenmap /DATA.
De map DATA heeft een aantal submappen waarop ik rechten heb gezet voor de verschillende gebruikersgroepen.

Zo is de map /DATA/ICT alleen toegankelijk voor de groep ICT (770) en is de map /DATA/Administratie toegankelijk voor de groep KANTOOR (770).
De documenten binnen deze map krijgen dan 660 rechten (of zouden die moeten krijgen, alhoewel 664 ook best is).

Nu wil ik ervoor zorgen dat als iemand een document in de map /DATA/ICT zet, iedereen van de groep ICT het document kan gebruiken, dus lezen en schrijven.
Standaard echter krijgt elk nieuw document 644 rechten met als owner en group degene die het bestand aanmaakt.

Met SGID (chmod 2770 /DATA/TEST) kan ik ervoor zorgen dat alle nieuwe documenten binnen de map /DATA/ICT als group automatisch de groep ICT krijgen.
Maar helaas krijgen de documenten dan nog niet de juiste bestandsrechten, die blijven op 644 staan ipv op 660. Daardoor kan alleen de eigenaar/maker het bestand bewerken en niet zijn collega's van de groep ICT.

Hoe kan ik dit oplossen?
Gebruikers vragen zelf de rechten aan te passen is niet echt een optie, dat wordt toch vergeten.
Bij windows servers (durf ik dat hier te zeggen?) heb ik hier nog nooit over hoeven nadenken, gaat altijd 'standaard' goed.

Met google kom ik er ook niet uit, als iemand al iets schrijft over SGID, dan hebben ze het alleen over group aanpassen, maar de volgens mij logische volgende stap om dan ook lees en schrijfrechten goed te zetten daar lees je nooit iets over

[odysseus]

Ik ben er niet zeker van dat ik precies goed lees wat je wil, maar als het is wat ik denk dat het is, kom je een heel eind met zoeken naar 'umask' .

[Seth4Chaos]

je moet inderdaad de umask van de gebruikers (standaard) veranderen, dit zal je in /etc/bashrc o.i.d. moeten doen zodat als een gebruiker inlogt zijn UMASK op 0002 staat bijvoorbeeld.

man umask

You can set umask in /etc/bashrc or /etc/profile for all users. By default most Linux distros will set it to 0022 (022) or 0002 (002).

[Verwijderd]

Ik heb hier laatst ook zo op zitten vloeken, het ging hierbij om een directory waarbij collega's niet hun umask hadden aanpast en ik zat dus met hetzelfde probleem. De antwoorden hierboven zijn inderdaad juist de default umask van 022 moet in 0002 worden aanpast. Linux zou echt de mogelijkheid moeten hebben om in dit soort situaties een umask op directories in te stellen. Waarschijnlijk is dit niet eenvoudig want heel veel gebruikers klagen hier al jaren over

[Rainmaker]

Je zou het ook eventueel kunnen oplossen door een ACL op die directory te zetten (setfacl en getfacl zijn je Google termen), maar dat is een maatje ingewikkelder.

[Verwijderd]

Een nadeel van ACL's is dat niet alle backup programma's daar lekker mee omgaan

[gertvdijk]

Verwijderd schreef op dinsdag 16 juni 2009 @ 23:30:
Een nadeel van ACL's is dat niet alle backup programma's daar lekker mee omgaan

rdiff-backup backs up one directory to another, possibly over a network. The target directory ends up a copy of the source directory, but extra reverse diffs are stored in a special subdirectory of that target directory, so you can still recover files lost some time ago. The idea is to combine the best features of a mirror and an incremental backup. rdiff-backup also preserves subdirectories, hard links, dev files, permissions, uid/gid ownership, modification times, extended attributes, acls, and resource forks.

Maar goed, ook rdiff-backup heeft zo z'n eigenaardigheden.

[Rainmaker]

Het ligt puur aan je backup pakket.

Er is volgens mij niet 1 groot / bekend pakket wat ACL's NIET meeneemt.

Kant-en-klaar shell scriptjes dus niet meegerekent.

(en ja, ik weet dat ik hierop gecorrigeert ga worden, iemand zal er vast 1 kunnen verzinnen...)

[Verwijderd]

Rainmaker schreef op woensdag 17 juni 2009 @ 01:37:
Het ligt puur aan je backup pakket.

Er is volgens mij niet 1 groot / bekend pakket wat ACL's NIET meeneemt.

Tar en verder zijn er de nodige problemen met ALC's en commando's zoals cp of mv (geweest?) met betrekking tot het niet meenemen van ALC's met het gebruik van die commando's

[ Voor 27% gewijzigd door Verwijderd op 17-06-2009 08:50 ]

[Rainmaker]

Verwijderd schreef op woensdag 17 juni 2009 @ 07:57:
[...]


Tar en verder zijn er de nodige problemen met ALC's en commando's zoals cp of mv (geweest?) met betrekking tot het niet meenemen van ALC's met het gebruik van die commando's

man tar (http://linux.die.net/man/1/tar):

code:

--acls
    this option causes tar to store each file's ACLs in the archive.

Maar volgens mij wordt het bij een moderne versie van tar gewoon meegenomen met -p

mv heeft er volgens mij nooit problemen mee gehad, cp in het verleden misschien wel, maar ook daarbij wordt het "gewoon" met -p meegenomen.

Maar of je dat een backuppakket wil noemen

[Verwijderd]

Mooi dat ze die tar, cp en mv ACL ellende gefixed hebben

tar = oldskool backup ftw

[gertvdijk]

Verwijderd schreef op woensdag 17 juni 2009 @ 20:51:
tar = oldskool backup ftw

tar = archive != backup.
Je kan een tar archive gebruiken als backup, dat is een van de toepassingen waarvoor je het zou kunnen gebruiken. Backup is: rdiff-backup, backintime, ...

[Verwijderd]

gertvdijk schreef op donderdag 18 juni 2009 @ 01:59:
[...]
Je kan een tar archive gebruiken als backup

Dat bedoel ik

[makje]

De discussie is al even verder gegaan zie ik, maar toch even een reaktie van mij.
Umask is voor ons de beste oplossing.

Onze gebruikers hebben hoge userID's dus we hebben voor de hoge userID's nu een umask van 002 en voor de systeemaccounts met lage ID's een umask van 022.

Naar ACL heb ik ook gekeken, maar die lijkt toch net ietsjes complexer. Vooral omdat er op internet veel verschillend verhalen over te vinden zijn, over wat nog niet werkt (zoals dus backupprogramma's), maar ook twijfelgevallen zoals kopiëren met Konqueror etc.

Wij hebben onze mappen netjes met rechten ingedeeld, onze groepen mogen altijd wat er in die mappen staat lezen en schrijven en door SGID gaat de groep bij elke map goed.

Umask voldoet daarom helemaal voor ons.
Bedankt voor de hulp