ruzie met permissies in linux

[timberleek]

Hallo

Voor een schoolopdracht moet ik klooien met permissies in linux.

Een leraar heeft een account waarin een gedeelde map wordt gemaakt (om opdrachten in te leveren enzo). Daarin komt een map voor elke leerling. In elke map heeft alleen de betreffende leerling en de leraar toegang (read & write). De rest van de leerlingen mogen die map uberhaupt niet ziet.

Dit dacht ik op te lossen door een softlink te plaatsen in de home directory van elke leerling rechtstreeks naar hun eigen map.

Aan het einde moet de docent alle permissies kunnen omgooien zodat alleen hij nog write permissies heeft, maar dat is nu niet van belang.


De mappen aanmaken en permissies zetten van de mappen lukt wel. Het leek me handig om de leraar eigenaar te maken en als group de user-only groep van de betreffende leerling.

Tot dusver niks raars.

Alleen als ik als leerling files aanmaak in zijn directory, krijgt hij de permissies van de leerling (dus leerling:leerling rwx:r) ipv de permissies van de parent folder.

Dit dacht ik op te kunnen lossen met SGID permissies, dus ipv chmod 770 deed ik chmod 2770 op de map. Uit de beschrijving begreep ik dat alles dat in de map wordt aangemaakt dan de permissies krijgen van de groep van de parent directory.

Dat werkte niet, en vermoedelijk weet ik ook waarom. De groep van de map is de leerlinggroep, dus de leraar krijgt niks. Dat dacht ik op te lossen door de leraar toe te voegen aan de usergroup van de leerling.

Maar ook dat werkt niet.

Nu ben ik het spoor een beetje bijster.


In het kort.
Ik heb een soft link naar een map, Alles dat in die map wordt gezet moet dezelfde permissies krijgen als van de map zelf. Automatisch (dus geen scriptje laten runnen oid).
ACL is niet de bedoeling, dat is voor opdracht b

[Osiris]

Dus elke leerling heeft een éigen group?

Is 't niet logischer om juist de owner de leerling te laten zijn en de group op de single group van de leraar?

[ Voor 58% gewijzigd door Osiris op 26-01-2014 00:26 ]

[timberleek]

ja de default group die wordt aangemaakt bij het aanmaken van de user.

dus als ik user "harrie" aanmaak wordt er ook een group "harrie" gemaakt met alleen die user erin (toch?)

[HollowGamer]

Uh.. Heb ik dit topic niet al eerder gezien?

Waarschijnlijk heeft een collega ook al deze vraag gestuurd, kijk daar eens in

[vanaalten]

Het lijkt inderdaad verdraaid veel op dit topic.

[Osiris]

timberleek schreef op zondag 26 januari 2014 @ 00:27:
dus als ik user "harrie" aanmaak wordt er ook een group "harrie" gemaakt met alleen die user erin (toch?)

Als jij dat zo gescript hebt wellicht. Maar dat is logischerwijs niet 'normaal'.

Meestal zit de user "harrie" gewoon in de group "users".

En "pietje", het dagelijkse werk-account van de systeembeheerder, zit bijv. in de group "wheel".

Waarom zou je een groepen-systeem maken als je vervolgens de groep identiek stelt aan de user? (Al kun je natuurlijk een user in meerdere groepen plaatsen, inclusief z'n identieke "eigen-user-group".. Maar ik zie 't nut er niet van in, aangezien je al het zelfde wat je met die groep kunt, ook met de user-rechten kunt doen. Aangezien je klaasje niet in de unieke "eigen-user-groep" van harrie gaat zetten e.d.

[ Voor 21% gewijzigd door Osiris op 26-01-2014 00:45 ]

[timberleek]

Dat is inderdaad dezelfde opdracht. Zal iemand zijn van een andere practicumgroep.
Dan ga ik die antwoorden ook even doorspitten.

Osiris schreef op zondag 26 januari 2014 @ 00:44:
[...]

Als jij dat zo gescript hebt wellicht. Maar dat is logischerwijs niet 'normaal'.

Meestal zit de user "harrie" gewoon in de group "users".

En "pietje", het dagelijkse werk-account van de systeembeheerder, zit bijv. in de group "wheel".

Waarom zou je een groepen-systeem maken als je vervolgens de groep identiek stelt aan de user? (Al kun je natuurlijk een user in meerdere groepen plaatsen, inclusief z'n identieke "eigen-user-group".. Maar ik zie 't nut er niet van in, aangezien je al het zelfde wat je met die groep kunt, ook met de user-rechten kunt doen. Aangezien je klaasje niet in de unieke "eigen-user-groep" van harrie gaat zetten e.d.

Dan ga ik daar verkeerd denk ik. Ik had begrepen dat die map zo werd aangemaakt.
Dat je daarom standaard bij permissies ook altijd dezelfde namen ziet staan bij user en group (als je ls -l doet)

[Osiris]

Geen idee welke distro dat is, maar normaliter (naar mijn weten) geldt dat alleen voor root:root en bepaalde services of daemons.

Zo draait Portage in Gentoo onder portage:portage, maar dat is natuurlijk omdat 't naast een applicatie ook een systeem is, waarbij het nuttig kan zijn users in de 'portage'-group te plaatsen.

[timberleek]

Gewoon Linux mint in mijn geval.

[Firedragon]

In debian/ubuntu/mint word er voor elke user een group aangemaakt

/etc/adduser.conf
# The USERGROUPS variable can be either "yes" or "no". If "yes" each
# created user will be given their own group to use as a default. If
# "no", each created user will be placed in the group whose gid is
# USERS_GID (see below).
USERGROUPS=yes

[CAPSLOCK2000]

Je distributie is hier totaal niet van belang. Maak zelf met de hand directories aan en blijf weg van adduser enzo die maken het alleen maar moeilijker omdat je dan ook nog moet uitzoeken wat die tools precies doen.

[Osiris]

CAPSLOCK2000 schreef op zondag 26 januari 2014 @ 02:58:
Je distributie is hier totaal niet van belang.

Nou ja, wel enigszins van belang als dat in onduidelijkheden resulteert als men maar gewoon iets aanneemt (waarmee ik ook op mezelf doel uiteraard )

[ Voor 7% gewijzigd door Osiris op 26-01-2014 11:52 ]

[timberleek]

Ok heb adhv onder andere dat andere topic wat wijzigingen gedaan.

De submappen (leerling mappen) zijn nu van de leerling met een leraargroep als groep (waar de docenten in zitten).
dus:
chown henk /home/main/henk
chgrp teachers /home/main/henk

Zowel henk als teachers hebben rwx toegang.
Tot zover werk het, maar als henk nu files aanmaakt in zijn map gaat het toch nog niet helemaal goed.
De user en groep zijn goed (henk:teachers), maar de permissies staan op rw voor henk, maar enkel r voor de teachers groep.

Dit moet rw/rw blijven.

sticky bit heb ik geprobeerd en ook de sgid permissie (chmod 1770 en 3770).

[Osiris]

`man umask`

[Verwijderd]

En niet de sticky bit zetten. Die doet iets heel anders. 2770 dus.

[timberleek]

Ok sticky bit is weer uit.

Ik dacht dat sticky bit enkel deed voorkomen dat mensen geen spullen kunnen verwijderen, maar goed.

umask lijkt inderdaad nuttig, en zoals ik het lees zou ik dan umask 007 moeten doen (full access voor de leerling en de teacher groep, geen permissies voor de rest), maar dat lijkt niks te veranderen. Nieuwe files zijn nog steeds rw/r. Ook umask 000 levert niks op.

Snap ik umask niet? of doe ik iets anders fout?
in de terminal heb ik gewoon als root "umask xxx" uitgevoerd.

[Osiris]

't Was een opdracht voor school, right?

Nou, dan zou ik maar eens een paar uurtjes het web afstruinen om `umask` echt goed te begrijpen

[Firedragon]

umask aanpassen lijkt me een beetje overbodig voor een simpelle opdracht als dit.
voor de paar mappen die aangemaakt moeten worden kan je net zo goed een chmod doen.

[Osiris]

Firedragon schreef op zondag 26 januari 2014 @ 15:23:
umask aanpassen lijkt me een beetje overbodig voor een simpelle opdracht als dit.
voor de paar mappen die aangemaakt moeten worden kan je net zo goed een chmod doen.

Het gaat om de bestanden die in die mappen terecht komen AFAIK. En 't mocht niet gescript.

[timberleek]

voor de mappen lukt het ook wel. Die zijn al goed.

Maar het probleem is nu dat de leerling in zijn map nieuwe files aanmaakt en die files nemen niet de permissies van de leerling map over. De teachers groep wordt wel meegenomen als groep, maar hij krijgt enkel read permissies. Dat moet automatisch read&write worden.

Er kan geen script voor runnen inderdaad. Er worden 3 bash scripts gemaakt. En het huidige script moet voor een opgegeven user een eigen map maken met bijbehorende permissies. De leerling (user) stopt hier files in om in te leveren en zolang de deadline nog niet verstreken is moeten leerling en leraar R/W permissies hebben.
Na de deadline wordt er een ander script gerund die de write permissies bij de leerling weghaalt.

[Verwijderd]

En stel dat een leerling voordat hij een bestand aanmaakt even "umask" intikt. Wat ziet die leerling dan?

[timberleek]

0022. Dus standaard permissies (alleen write access voor user)

[Verwijderd]

Dus dan is het eigenlijk heel logisch dat er geen write rechten voor de groep zijn. Kortom, los dit even op in de user profiles en je bent weer een stukje verder.

[timberleek]

Ja ik kan het wel handmatig fixen, maar ben nog aan het zoeken of dat ook in een script kan.

[begintmeta]

Alles wat handmatig kan kan ook in een script.

[igmar]

Gebruik een ACL om dit op te lossen.

[Verwijderd]

Dat is nergens voor nodig.

[Osiris]

En niet de TS z'n opdracht.

[timberleek]

ACL's mogen niet in opdracht A. Die worden gebruikt bij B.

Maar ik heb het nu 95% werkend. Alleen zag ik dat bij mint umask niet in .bashrc (of zoiets) staat. Met losse umask wijziging bij die user werkt alles al. Moet alleen nog even kijken waar ik dat "tegenwoordig" per user kan wijzigen

[Osiris]

timberleek schreef op maandag 27 januari 2014 @ 22:18:
Alleen zag ik dat bij mint umask niet in .bashrc (of zoiets) staat.

Dan zet je 't erin?

[timberleek]

De hele file bestaat niet.

Ik nam eigenlijk aan dat het verplaatst was

edit
nevermind, heb het al gevonden.
Het staat niet in bashrc, maar in .profile


edit2:
ok toch nog een vraagje :-)

Ik maak nu een account aan en verander in de home directory het bestand .profile.
Er staat een comment #umask 022, die verander ik naar umask 007 (ook zonder # dus).

Dit werkt, alleen moet de aangepaste profile nog opnieuw geladen worden om het te laten werken.
Dit moet alleen gebeuren in het script.

Ik kan het in terminal doen door: su - user (met streepje).
maar hoe laat ik het herladen in het script?

ik kwam . /home/user/.profile tegen, maar dat fikst het niet jammer genoeg

[ Voor 99% gewijzigd door timberleek op 27-01-2014 23:25 ]

[Thc_Nbl]

lees:

http://dsl.org/cookbook/cookbook_9.html

dan ga je er helemaal uitkomen en heb je er gelijk wat van geleerd.

en daar waar je .profile gezien heb staat ook .bashrc kijk daar ok maar eens in.
en de umask heb je in princiepe niet nodig als het eind resultaat moet zijn dat de leraar de leerlingen alleen de toegang ontneemt. dat er b.v. 700 overblijft op de map.
heb je wel een keer uitgelogd en weer ingelogd, en het blijft... dan staat de umask geforceerd in
/etc/pam.d/common-session

Je begint in iedergeval goed .. ( eigenlijk heb je het antwoord zelf in je vraag gezet.. )


...Het leek me handig om de leraar eigenaar te maken en als group de user-only groep van de betreffende leerling....

zet de "setgid bit" ...

setgid bit en stop de leeraar in alle leerling groepen. ( 770) is dan voldoende.

en beter : chmod u+r+w+X,g+r+w+X,o-r-w-x gebruiken..


suc6

[timberleek]

mijn eigen useraccount heeft wel .bashrc, maar bij de gebruikers die ik aanmaak (met useradd) staat hij niet (.profile wel).

umask gebruik ik voor de gebruikersaccounts omdat een aangemaakt bestand standaard enkel read access toekent aan de group (de teachers) door de umask (default = 022). Die wilde ik veranderen naar 00x om de teacher ook automatisch write access te geven (ook voor de deadline moet de teacher write access hebben).

Bij de deadline gooi ik gewoon de normale permissies om, daar heeft umask inderdaad niks mee van doen.

ik heb in terminal wel su user gedaan en dan weer exit na het veranderen van .profile. Dan is umask niet bijgewerkt (en dus nog steeds 0022). alleen als ik su - user (met login shell) doe werkt hij umask bij naar de nieuwe waarde die in .profile staat. Ik ben nu alleen nog aan het kijken naar een manier om dat bij te werken vanuit het bash script. Verder is het script af.

Bedankt voor de link trouwens, ik ga hem even doorworstelen

[Hero of Time]

Er is een verschil tussen useradd en adduser. De een pakt wel /etc/skeleton, de ander niet. Wordt skeleton gebruikt, dan krijgt elke gebruiker ook een .bashrc en nog een paar dingetjes.

Maar de umask kan je ook in /etc/bash.bashrc zetten, al moet je wel goed opletten dat je niet ondertussen wat anders sloopt. Pas dus op hiermee!

[HollowGamer]

Vergist me zelf ook altijd tussen die twee: useradd en adduser

De andere gebruik je bijvoorbeeld ook om iemand aan een (sub)groep toe te voegen, zie:
https://wiki.archlinux.org/index.php/Users_and_Groups

Deze zijn allemaal mogelijk:
usermod -aG [additional_groups] [username]
gpasswd --add [username] [group]
useradd -a [username] [group]

Het maakt het er niet eenvoudiger op..

[Hero of Time]

En dan heb je ook nog vipw met z'n verschillende parameters (--passwd, --shadow, --group) om 't als tekstbestand te doen (in principe te doen bij bestaande users om aan te passen).

[Osiris]

Ik edit gewoon handmatig /etc/group en /etc/group- (wtf is 't verschil überhaupt Ah, gewoon een backup door die proggies schijnbaar..), juist omdat al die kutprogramma's zo onduidelijk zijn

[ Voor 16% gewijzigd door Osiris op 29-01-2014 15:14 ]

[Hero of Time]

Ehm, niet echt een 'backup', maar de shadow copy ervan. Er is een commando dat controleert of de boel nog wel in orde is voor je users en groups. Is de shadow versie niet gelijk aan de gewone, dan gaat-ie klagen. Het usermod en groupmod commando past beide aan zodat ze niet out of sync raken.

[Osiris]

Dan liegt "Google"