[linux] User mag alleen bestanden van hemzelf verwijderen?

[Verwijderd]

Beste mensen,

Op dit moment sla ik in de homedir van de user een bestandje .userinfo op (owned by root, group root) waarin wat extra informatie over een gebruiker staat. Maar omdat de gebruiker wel de eigenaar is van z'n eigen homedir (daar mag hij in schrijven), kan hij het bestand .userinfo verwijderen, ookal is het niet van hem! En dat mag absoluut niet gebeuren.

Een tijd geleden had ik hetzelfde probleem, en dat heb ik toen op weten te lossen, maar ik weet niet meer hoe... Overal gezocht, maar ik kan er niet meer achter komen. Ik meen dat het iets te maken had met sticky-bits, maar zeker weten doe ik het niet... Kan iemand mij uit de brand helpen? Alvast bedankt !

[igmar]

chattr +i bestand

[Verwijderd]

Hmmm... Is dat niet er rigoreus? Dat beschermt het bestand tegen wijzigen/deleten in het algemeen, ook voor root, toch? Is er gewoon een soort bit dat je in kunt stellen op een directory, dat er voor zorgt dat een user alleen files/directories kan wissen waarvan hij zelf de eigenaar is?

[Guider]

volgens mij kan je dit oplossen door het sticky bit voor je rechten te zetten. dus een voor beeld zou zijn

chmod 1777 filename

Het gaat dus om het 1'tje wat er voor je "normale" rechten staat.

[ Voor 22% gewijzigd door Guider op 24-03-2004 10:50 ]

[Verwijderd]

Hmmm... Dat lijkt niet te werken. Stel, mijn user heet piet (home gewoon in /home/piet), dan doe ik dus

code:

chmod 1777 /home/piet/.userinfo

Dat voorkomt niet dat de user dat bestand kan verwijderen. Ook

code:

chmod 1777 /home/piet

help niet...

[blaataaps]

In een directory met permissies 777 + sticky mag iedereen bestanden aanmaken en verwijderen, maar alleen als ze zelf eigenaar van die bestanden zijn, daardoor mag iedereen in /tmp dingen aanmaken, maar niet andermans dingen verwijderen, wat normaal bij 777 wel zo zou zijn. Maar het 'alleen verwijderen als het van jezelf is'-effect gaat verloren als je gewoon eigenaar bent van de directory, dus in het geval van een homedir is het niet echt handig, ook omdat 777 op je homedir niet echt slim is.

[Guider]

Is er geen aparte delete optie die je kan instellen op mappen en daar dan een user aanhangen??

[Verwijderd]

Maar het moet toch mogelijk zijn om dingen op te slaan in de homedir van een user, die niet door hemzelf gewijzigd (of verwijderd) kunnen worden?

[Wilke]

Hmm, het klopt wel, maar ik kan begrijpen dat je het anders wil.

Het werkt wel als je een subdir maak in de directory home, en die eigendom maakt van root:

code:

cd
su
mkdir .vanroot
echo test > .vanroot/afblijvenjij
exit
rm -rf .vanroot

levert op rm: cannot remove `.vanroot/afblijvenjij': Permission denied

Waarom dit wel werkt: je kunt een directory alleen verwijderen als hij leeg is, en dat krijg je niet voor elkaar want er staat een bestand in de directory wat niet van jou is en je dus ook niet kunt verwijderen; omdat de dir zelf ook niet van jou is heb je er namelijk geen schrijfrechten

Tsja, het is denk ik wel zo 'bedoeld' zoals het is (dus als een dir van jou is, kun je bestanden er in gewoon wissen, daar is niks tegen te doen; tenminste niet zonder zeer ongewenste bijverschijnselen).

Een misschien netter alternatief is om die .userinfo gewoon ergens anders neer te zetten, ik noem maar iets: /var/db/userinfo/<username> . Ik weet ook niet wat je er verder mee wil hoor, maar gewoon een suggestie.

offtopic:
NB. bovenstaande voorbeeld werkt i.h.a. niet op NFS-shares, dus je kunt dit niet doen als de homedir op NFS staat. Je bent gewaarschuwd.

[Verwijderd]

Maar dan blijft het probleem, dat ik geen controle meer heb over het bestand ".forward" in de homedir. Ik wil namelijk niet dat m'n users rare dingen uit gaan halen met de mail... Dan is dus de enige oplossing "chattr +i .forward" om .forward te beschermen? Hmmm... wel omslachtig!

[Spider.007]

Is het geen idee om een softlink met +i te maken en die te laten verwijzen naar een .forward die jij als root zonder problemen kunt aanpassen? De link kan niet verwijderd worden, tegelijkertijd kun jij zonder moeilijk te doen het bestand wel aanpassen als root

[Guider]

De recht in linux blijven omslachtig ik heb al gemerkt. Als je het gaat vergelijken met windows (Wat hier eigenlijk niet mag natuurlijk) dan zit windows met rechten veel makkelijker in elkaar en heb je meer attributen tot je beschikking.....

[Verwijderd]

Dat ben ik gedeeltelijk met je eens. Natuurlijk is het makkelijk dat je in Windows per-user en per-group rechten kunt instellen, maar aan de andere kant brengt dat ook een hoop organisatie met zich mee. In principe kun je met Linux ook heel veel, als je het maar goed organiseert. Maar, er blijven altijd punten zoals het probleem van mij, en die zijn onder Windows ongetwijfeld wel op te lossen.

[igmar]

Guider schreef op 24 maart 2004 @ 12:01:
De recht in linux blijven omslachtig ik heb al gemerkt. Als je het gaat vergelijken met windows (Wat hier eigenlijk niet mag natuurlijk) dan zit windows met rechten veel makkelijker in elkaar en heb je meer attributen tot je beschikking.....

Die 'attributen' zitten ook al in 2.6, en in de ACL patches voor 2.4. Niks omslachtigs aan.

[Verwijderd]

Spider.007 schreef op 24 maart 2004 @ 12:01:
Is het geen idee om een softlink met +i te maken en die te laten verwijzen naar een .forward die jij als root zonder problemen kunt aanpassen? De link kan niet verwijderd worden, tegelijkertijd kun jij zonder moeilijk te doen het bestand wel aanpassen als root

Je kunt "chattr +i" niet uitvoeren op de symlink. Dan worden de nieuwe attributen op het echte bestand toegepast, en kan de gebruiker de symlink nog verwijderen. Hmmm... Dit begint vervelend te worden.

[arikkert]

Verwijderd schreef op 24 maart 2004 @ 11:56:
Maar dan blijft het probleem, dat ik geen controle meer heb over het bestand ".forward" in de homedir. Ik wil namelijk niet dat m'n users rare dingen uit gaan halen met de mail...
Dan is dus de enige oplossing "chattr +i .forward" om .forward te beschermen? Hmmm... wel omslachtig!

BOFH
misschien kun je in de configuratie/builden van procmail of ander programma dat die .forward gebruikt een andere plek definieren voor dat bestand bijv $HOME/.vanroot/.forward.

[ Voor 4% gewijzigd door arikkert op 24-03-2004 13:47 ]

[Wilke]

arikkert schreef op 24 maart 2004 @ 13:46:
BOFH

Niet helemaal zo vreemd als je denkt; met .forwards kun je een hoop ellende veroorzaken als onwetende of niet nadenkende user (mailloops bijvoorbeeld).

[Verwijderd]

Hmmmm... Nou, ik heb gewoon op .forward en .userinfo "chattr +i" gedaan. Dat is wel een beetje omslachtig, maar ik heb m'n scripts aangepast om daar op te letten. Als er nog iemand anders een andere oplossing heeft, dan hoor ik die graag!

[EdwinG]

Is het de bedoeling dat het bestand niet te verwijderen is, of mag het ook niet bewerkt worden?
Met alleen verwijderen is ook nog chattr + u te gebruiken.