[ACL] Gekloot met rechten en het kopieren van files

[_eXistenZ_]

Gister heb ik op mijn Gentoo-servertje ACL's aan de gang gekregen, omdat ik soms tegen de beperkingen van het normale user/group/other-systeem aanliep.

Ik heb een script runnen die wat files van het internet af trekt en deze in map 1 neerzet, die zijn eigen ACL heeft. Hierdoor krijgen de bestanden die aangemaakt worden automatisch de bijbehorende default-ACL die voor die map geldt.

Zodra de bestanden gedownload zijn worden deze verplaatst naar map 2, welke ook zijn eigen ACL heeft, dus andere gebruikers mogen in deze map met andere rechten.

Bij het verplaatsen van de bestanden worden de ACL's van de bestanden gewoon overgenomen, waardoor ik alsnog handmatig de rechten moet goed gaan zetten:

Bash:

$ touch blaat
$ getfacl blaat | setfacl --set-file=- *
$ rm blaat

Is er geen andere manier om ACL zo te configureren dat bestanden altijd de rechten van de mappen krijgen? Ik wil eigenlijk helemaal niet dat bestanden zelf mogen bepalen welke rechten ze hebben, maar dat deze afhankelijk van de mappen bepaald worden, ook bij verplaatsen of kopiëren van bestanden.

Ik zag al wel op internet in de schaarse informatie die er is over ACL, dat je wel kan kopieren en dan de extended attributes van een file weg kan gooien, maar dan nog hebben ze niet de ACL's die ik wil, plus ik wil niet kopieren maar verplaatsen want opslagruimte groeit niet op me rug

[Rainmaker]

Als de "default" ACL op de directory goed staat, zou je gewoon moeten kunnen kopieeren en moet het bestand de rechten van de directory overnemen. Gewoon geen "preserve-permissions" en / of -p en / of -a o.i.d. meegeven.

Eventueel kun je cp ook de rechten laten negeren door --copy-contents mee te geven, maar bij mij neemt ie standaard helemaal geen permissies mee. mv doet dit wel. Eventueel zou je rsync kunnen gebruiken met --delete-during, die standaard ook geen rechten meeneemt.

code:

[user1] tmp $ getfacl bla
# file: bla
# owner: user1
# group: group1
user::rw-
user:user1:r--
group::rw-
mask::rw-
other::r--
[user1] tmp $ cp bla bla2
[user1] tmp $ getfacl bla2
# file: bla2
# owner: user1
# group: group1
user::rw-
group::rw-
other::r--

[_eXistenZ_]

Ik wil liever niet kopiëren omdat het script dat ik gebruik gewoon PHP is (Zit ook een web-frontendje bij enzo) waarin ik gewoon rename() gebruik Maar als er niks anders opzit doe ik wel eerst kopieren, en dan verwijderen vanuit php... Geen andere mogelijkheid dus om dit toch doormiddel van een standaard move voor elkaar te krijgen? (Behalve rsync, maar dat wordt me te omslachtig alleen om wat permissies goed te krijgen)

Tevens zijn alle files die al bestonden waarvan ik gister de ACL ingesteld heb, wel met +x ingesteld, maar zodra ik een nieuwe file maak komt de +x niet mee. Vind ik voor de rest niet erg, het zijn geen uitvoerbare bestanden, maar ik houd wel van een beetje nette indeling dus als de rechten hetzelfde zouden kunne worden zou ik wel prettig vinden... (Dus niet de ene helft +x dus felgroen, en de andere helft zonder, dus knalroze in mijn Putty)

Ik kan dit ook handmatig doen maar het gaat om een groot aantal (100+) mapjes dus het lijkt mij met alle flexibele tools vanaf de commandline niet echt nodig om hier uren aan kwijt te moeten zijn

/edit

Wat je zegt over dat cp automatisch de nieuw rechten zou toepassen klopt volgens mij niet, want als ik een bestand kopieer van een andere map naar een ACL-ingestelde map krijgt dat bestand niet de default ACL maar houd ie gewoon wat lullige andere rechten... pas als ik een nieuw bestand touch krijgtie wel de goeie ACL...

/edit 2

En nu weer wel ik snap er niks meer van

[ Voor 68% gewijzigd door _eXistenZ_ op 22-02-2010 15:12 ]

[Rainmaker]

_eXistenZ_ schreef op maandag 22 februari 2010 @ 14:59:
Ik wil liever niet kopiëren omdat het script dat ik gebruik gewoon PHP is (Zit ook een web-frontendje bij enzo) waarin ik gewoon rename() gebruik Maar als er niks anders opzit doe ik wel eerst kopieren, en dan verwijderen vanuit php... Geen andere mogelijkheid dus om dit toch doormiddel van een standaard move voor elkaar te krijgen? (Behalve rsync, maar dat wordt me te omslachtig alleen om wat permissies goed te krijgen)

rename() geeft een nieuwe bestandsnaam aan dezelfde inode. Dat betekend inderdaad dat de permissies bewaard blijven.

Tevens zijn alle files die al bestonden waarvan ik gister de ACL ingesteld heb, wel met +x ingesteld, maar zodra ik een nieuwe file maak komt de +x niet mee. Vind ik voor de rest niet erg, het zijn geen uitvoerbare bestanden, maar ik houd wel van een beetje nette indeling dus als de rechten hetzelfde zouden kunne worden zou ik wel prettig vinden... (Dus niet de ene helft +x dus felgroen, en de andere helft zonder, dus knalroze in mijn Putty)

Als het geen executable bestanden zijn, zet de bit dan ook niet... Stukje veiligheid. Ik zou degene met dan even chmod'den.

Ik kan dit ook handmatig doen maar het gaat om een groot aantal (100+) mapjes dus het lijkt mij met alle flexibele tools vanaf de commandline niet echt nodig om hier uren aan kwijt te moeten zijn

code:

find . -type f -exec chmod -x {} \;

/edit

Wat je zegt over dat cp automatisch de nieuw rechten zou toepassen klopt volgens mij niet, want als ik een bestand kopieer van een andere map naar een ACL-ingestelde map krijgt dat bestand niet de default ACL maar houd ie gewoon wat lullige andere rechten... pas als ik een nieuw bestand touch krijgtie wel de goeie ACL...

/edit 2

En nu weer wel ik snap er niks meer van

Ik ook niet

Op het moment dat je default ACL goed staat, moet dit werken.

code:

setfacl -d -m d:u:ik:rw directory

(niet getest)

[_eXistenZ_]

Ik heb het opgelost door gewoon

PHP:

exec('getfacl ' . MOVETODIR . ' | setfacl --set-file=- ' . MOVETODIR . '/' . $file);
exec('setfacl m:rw-' . MOVETODIR . '/' . $file);

in mijn script op te nemen, hiermee worden de rechten van de dir overgedragen op de file die er net bij geplaatst is en het execute bit word door de mask er weer netjes afgesloopt, zoals ook zo gebeurt als je een nieuwe file zou touchen De dirs hebben namelijk +x nodig om via Samba bereikbaar te zijn.

Bedankt voor alle hulp!