Permissies in Linux

[DeepFreeze.NL]

Ik zit met een simpele vraag waarop ik het antwoord niet kan vinden en ook niet beschreven staat in mijn boek "Linux Systeembeheer". Het volgende:

Op mijn server heb ik Ubuntu 7.10 geïnstalleerd. Daarop heb ik twee gebruikers aangemaakt genaamd "admin1" en "admin2". Nu ben ik ingelogd als gebruiker admin1 en heb ik een tekstbestand aangemaakt in de homedirectory en deze met chmod 777 voor iedereen alle rechten gegeven.

Nu wil ik de eigenaar van het bestand gaan veranderen naar admin2. Dat doe ik (nog steeds ingelogd als admin1) met het commando "chown admin2 test". Ik krijg dan een "permission denied" melding. Waarom krijg ik deze melding? admin1 zou toch zelf mogen beslissen dat admin2 de nieuwe eigenaar wordt? Of moet er gebruik gemaakt worden van het root account om de eigenaar of groep van een bestand te mogen wijzigen?

[MrDry]

Volgens mij wel ja. sudo chown admin2 test zou moeten werken....

[Sprite_tm]

Even doorklikken in Google: http://www.gnu.org/softwa...nly-root-chown-files_003f

[Semyon]

Alleen de eigenaar van een file of de root mag bepalen wie er vanaf dan de eigenaar zou zijn. Anders zou het wat zijn zeg, dan zou ik onmiddelijk mezelf de eigenaar maken van belangrijke sys files en het systeem onderuit halen.

Schrijf rechten is niet voldoende om je dan ook de file toe te eigenen...

Verder is het vaak niet nodig vaak te veranderen van eigenaar, het is beter het in een goede groep neer te zetten, dan is het verder helemaal niet belangrijk wie de eigenaar is.

[DeepFreeze.NL]

Semyon schreef op dinsdag 25 maart 2008 @ 14:43:
Alleen de eigenaar van een file of de root mag bepalen wie er vanaf dan de eigenaar zou zijn. Anders zou het wat zijn zeg, dan zou ik onmiddelijk mezelf de eigenaar maken van belangrijke sys files en het systeem onderuit halen.

Schrijf rechten is niet voldoende om je dan ook de file toe te eigenen...

Verder is het vaak niet nodig vaak te veranderen van eigenaar, het is beter het in een goede groep neer te zetten, dan is het verder helemaal niet belangrijk wie de eigenaar is.

Dat is het vreemde juist, de eigenaar mag de eigenaar (zichzelf dus) van het bestand niet wijzigen naar een andere eigenaar.

[asing]

Mij lukt het met Fedora Core 6 wel. Ik doe het via de GNome interface.

[user109731]

DeepFreeze.NL schreef op dinsdag 25 maart 2008 @ 14:49:
Dat is het vreemde juist, de eigenaar mag de eigenaar (zichzelf dus) van het bestand niet wijzigen naar een andere eigenaar.

Het lijkt misschien vreemd, maar zoals je ziet in de link van sprite_tm voorkomt het een aantal lastige problemen. User A zou bijvoorbeeld disk quota kunnen misbruiken door user B met een groot bestand op te zadelen. Wanneer user B geen toegang heeft tot die directory kan hij hier niets aan doen zonder iemand met root-rechten in te schakelen. Of een user kan een malafide bestand toewijzen aan iemand anders, waardoor die ander verdacht word

[begintmeta]

Note that, by default, you must use sudo to change a file's owner or group.

impliciet staat er dat 't dus te veranderen zou moeten zijn, maar er zijn al argumenten daartegen gepost.

[ Voor 42% gewijzigd door begintmeta op 25-03-2008 15:05 ]

[zomertje]

Edit: werkt dus anders dan ik gedacht had.... misschien heb ik te vaak rootrechten
En op AIX mag het inderdaad ook niet

[ Voor 122% gewijzigd door zomertje op 25-03-2008 15:09 ]

[DeepFreeze.NL]

Bedankt voor de uitleg, het is voor mij nu duidelijk waarom sudo gebruikt moet worden voor het wijzigen van de rechten

[zeroxcool]

Het makkelijkste voorbeeld waarom dit niet zou mogen is misschien nog wel om als user 'bar', voor de file 'getclearpass' setuid bit te setten, en dan het bestand door root te laten chownen...

[Verwijderd]

DeepFreeze.NL schreef op dinsdag 25 maart 2008 @ 15:22:
Bedankt voor de uitleg, het is voor mij nu duidelijk waarom sudo gebruikt moet worden voor het wijzigen van de rechten

Sudo wordt door veel beheerders ook als "lastig" beschouwd.

Kan ze geen ongelijk geven

[luteijn]

zeroxcool schreef op dinsdag 25 maart 2008 @ 17:04:
Het makkelijkste voorbeeld waarom dit niet zou mogen is misschien nog wel om als user 'bar', voor de file 'getclearpass' setuid bit te setten, en dan het bestand door root te laten chownen...

Afaik wordt het s-bitje op de user gestript bij een chown, zowel bij oudere unixen die je wel files laten weggeven als in linux:

code:

sh-3.1# touch aap
sh-3.1# ls -l aap
-rw-r--r-- 1 root root 0 2008-03-25 21:56 aap
sh-3.1# chmod a+s aap
sh-3.1# ls -l aap
-rwSr-Sr-- 1 root root 0 2008-03-25 21:56 aap
sh-3.1# chown luteijn aap
sh-3.1# ls -l aap
-rw-r-Sr-- 1 luteijn root 0 2008-03-25 21:56 aap
sh-3.1# chgrp users aap
sh-3.1# ls -l aap
-rw-r-Sr-- 1 luteijn users 0 2008-03-25 21:56 aap

P.

[Verwijderd]

DeepFreeze.NL schreef op dinsdag 25 maart 2008 @ 15:22:
Bedankt voor de uitleg, het is voor mij nu duidelijk waarom sudo gebruikt moet worden voor het wijzigen van de rechten

Lukt het al een beetje met de casus?

[DeepFreeze.NL]

Verwijderd schreef op woensdag 26 maart 2008 @ 10:44:
[...]


Lukt het al een beetje met de casus?

Haha, ja gaat wel prima. Ik ga vandaag alle presentaties afronden.
Ik hoop alles vrijdag te kunnen opleveren.

[begintmeta]

presentaties hier posten aub

[RemcoDelft]

DeepFreeze.NL schreef op dinsdag 25 maart 2008 @ 14:49:
[...]Dat is het vreemde juist, de eigenaar mag de eigenaar (zichzelf dus) van het bestand niet wijzigen naar een andere eigenaar.

Je hebt het over "admin1" en "admin2", maar dat zijn dus "gewone" gebruikers zonder speciale rechten?
Dan is het niet zo gek dat een gebruiker de owner van z'n files niet kan aanpassen, anders zou iedereen files "op andermans naam" kunnen maken, en het hele idee van permissies is nou juist dat dat niet kan.

"sudo" vind ik ook een ellendige uitvinding, na 5 jaar Slackware gevolgd door 5 jaar Gentoo is het eerste wat ik op een Ubuntu-installatie doe "sudo passwd", zodat "su -" gewoon weer werkt:)

[BCC]

RemcoDelft schreef op woensdag 26 maart 2008 @ 19:00:
[...]
"sudo" vind ik ook een ellendige uitvinding, na 5 jaar Slackware gevolgd door 5 jaar Gentoo is het eerste wat ik op een Ubuntu-installatie doe "sudo passwd", zodat "su -" gewoon weer werkt:)

Ik ook, maar het heeft zeker toepassingen. Vaak is het gewoon korter.
Als je bijvoorbeeld even een service moet schoppen is:

code:

sudo /etc/init.d/apache2 restart

korter dan

code:

su -
/etc/init.d/apache2 restart
exit

[begintmeta]

En afaik is het met sudo wat makkelijker om een fijnmaziger permissiebeleid te voeren. Bijvoorbeeld een gebruiker alle wachtwoorden behalve bepaalde-wachtwoorden mogen laten veranderen etc Maar het is wel lastiger beheren om dat goed voor elkaar te krijgen.

[robbert]

RemcoDelft schreef op woensdag 26 maart 2008 @ 19:00:
"sudo" vind ik ook een ellendige uitvinding, na 5 jaar Slackware gevolgd door 5 jaar Gentoo is het eerste wat ik op een Ubuntu-installatie doe "sudo passwd", zodat "su -" gewoon weer werkt:)

Probeer eens sudo -s...

/me robbert snapt al dat gezeik op sudo niet...

[ Voor 10% gewijzigd door robbert op 26-03-2008 19:35 ]

[Wolfboy]

De reden dat chown als normale gebruiker niet mag in de meeste unices is dat het gebruikt werd om de quotas te omzeilen, gewoon alle grote bestanden chownen naar een andere eigenaar en je hebt opeens weer ruimte genoeg binnen je quota

[Verwijderd]

Waarom durft niemand hier iets te doen als root ?

Ik heb wel vaker ervaren dat mensen bang zijn om over root te spreken en dat vind ik ronduit raar.

Root is helemaal niet zo'n probleem, echt zoveel systeem die gewoon als gebruiker X van systeem Y inloggen op systeem Z als root zijnde en hun ding doen.

Waarom in godsnaam moeilijk doen als er legio andere zaken zijn die je in je beveiliging op orde moet hebben.

Root is voor de scriptkiddies niet echt belangrijk meer tegenwoordig, tenzij ze rm -rf /* doen nadat ze je systeem gebruikt hebben

Echter, opnieuw installen wil je toch na een compromize

[ Voor 5% gewijzigd door Verwijderd op 26-03-2008 21:26 ]

[deepbass909]

Ik zit bijna elke sessie die ik of op m'n laptop of op m'n gewone pc start wel in een su (root) omgeving. Als is het alleen maar om te updaten (Gentoo, vanaf de cmd-line). Ik snap ook nooit waarom sommige mensen zo paniekerig doen over de root-omgeving. Zolang je maar niet "werkt" in die omgeving (internetten, chatten om maar 2 dingen te noemen).

[Verwijderd]

Programma's starten als root zou link kunnen zijn als er een lek in zit.

Tja, mijn fietsband is ook wel eens lek en de velg gaat echt niet direct kapot hoor

[zomertje]

Je wil gewoon niet elke gebruiker rootrechten geven. Jullie denken teveel in 'linux wordt alleen door mij gebruikt op mn eigen pc' en niet in 'we hebben een server en daar zitten 50 verschillende mensen op'

En daarnaast, als je het niet nodig hebt, waarom zou je dan als root werken? Thuis werk ik zelden als root, op het werk bijna altijd. Maar op het werk ben ik altijd zaken aan het aanpassen en thuis ben ik vaak gewoon aan het internetten en chatten

[Sprite_tm]

Komt bij dat je de menselijke fout vergeet. Vergeet bij een actie als 'rm -rf ./*' maar eens de punt... als root ben je je OS kwijt, als user krijg je genoeg access denied-meldingen dat je waarschijnlijk op ctrl-C kan drukken zonder dat er daadwerkelijk iets gedeleted is.

[RemcoDelft]

Sprite_tm schreef op donderdag 27 maart 2008 @ 08:49:
Komt bij dat je de menselijke fout vergeet. Vergeet bij een actie als 'rm -rf ./*' maar eens de punt... als root ben je je OS kwijt, als user krijg je genoeg access denied-meldingen dat je waarschijnlijk op ctrl-C kan drukken zonder dat er daadwerkelijk iets gedeleted is.

Doet me denken aan de keer dat ik `rm -rf .*` deed in /tmp, als root (met als doel alle files/directories met een punt aan het begin te deleten)..... Ach, ik kon er wel om lachen...
Tegenwoordig geeft rm de melding dat-ie ".." niet meeneemt, maar dat was toen nog niet zo.

[Verwijderd]

Daarom geef ik altijd het volledige pad op als ik op servers op mijn werk als root bezig ben. Dus altijd rm -rf /tmp/* Kan je vrijwel nooit de mist mee in gaan

[RemcoDelft]

Verwijderd schreef op donderdag 27 maart 2008 @ 18:52:
Daarom geef ik altijd het volledige pad op als ik op servers op mijn werk als root bezig ben. Dus altijd rm -rf /tmp/* Kan je vrijwel nooit de mist mee in gaan

Jawel, hiermee zou je exact op dezelfde manier de mist in zijn gegaan... Ik zou dan namelijk /tmp/.* gedaan hebben (want * alleen laat alle .-files staan), en /tmp/.* zou dan ook /tmp/.. bevatten, waarmee je weer in / zit. Maar gelukkig is die bug gefixt

[Verwijderd]

zomertje schreef op donderdag 27 maart 2008 @ 08:23:
Je wil gewoon niet elke gebruiker rootrechten geven. Jullie denken teveel in 'linux wordt alleen door mij gebruikt op mn eigen pc' en niet in 'we hebben een server en daar zitten 50 verschillende mensen op'

En daarnaast, als je het niet nodig hebt, waarom zou je dan als root werken? Thuis werk ik zelden als root, op het werk bijna altijd. Maar op het werk ben ik altijd zaken aan het aanpassen en thuis ben ik vaak gewoon aan het internetten en chatten

Dat is dan toch Appels met Peren vergelijken ?

Denk je dat ik op mijn Linux werkstation als root werk ?

[Verwijderd]

RemcoDelft schreef op donderdag 27 maart 2008 @ 19:48:
[...] (want * alleen laat alle .-files staan)

Dat hangt van de instellingen van je shell af Ik geef je een hint: shopt -o dotglob