[Rechten] Kan dit zonder sudo, zo niet, hoe sudo gebruiken?

Pagina: 1
Acties:
  • 115 views sinds 30-01-2008
  • Reageer

  • pierre-oord
  • Registratie: April 2002
  • Laatst online: 15-01 10:55
Om een aantal installatie taken te automatiseren, heb ik een script geschreven met gebruik van sudo.

Voorbeeld:

/home/hoofduser/script.php <-- rechten homedir 700

/home/user01/ <-- is locatie waar files moeten worden uitgepakt etc etc, rechten 700
/home/user02/ <-- is locatie waar files moeten worden uitgepakt etc etc, rechten 700

Allen in dezelfde group (maar maakt niet uit want de grouprechten gebruik ik dus eigenlijk niet).

Ik maak gebruik van PHP zoals je al ziet voor de scripting, omdat ik deze taal goed beheers.

Nu wil ik echter dat de user01 en user02 niet bij elkaar kunnen in de directory kunnen lezen en schrijven en niet in de hoofduser directory kunnen komen. Ik heb ze nu in dezelfde group zitten, dus heb ik de rechten op de directory 700 staan. Echter, user "hoofduser" moet wél in die directory mogen komen om bestanden te extracten en daarna te bewerken.

Het extracten enzo gaat wel goed, ik gebruik nu iets als "sudo -u user01 COMMANDO". (in visudo nopasswd ingesteld voor user "hoofduser"). Nu wil ik alleen ook dingen doen zoals kijken of een bestand bestaat. Met PHP gebruikte ik eerst gewoon de functie "file_exists" maar dat werkt in dit geval niet omdat er geen rechten zijn op de directory user01. Iets met sudo bouwen wordt wel erg ingewikkeld voor zoiets.

Ik overweeg nu om het simpel op te lossen door de PHP file te laten starten onder de "user01" bijvoorbeeld. Probleem: ik heb files nodig uit de "hoofduser" directory, maar ik wil niet dat de gebruikers die directory kunnen lezen! En sudo-en vanuit die gebruiker is geen optie, maar zelfs dan zou ik geen rechten hebben om de file te kopieren in een "user01" directory!

Bied linux op de een of andere manier een mogelijkheid om de user "hoofduser' wel in de mappen user01, user02 toe te laten, terwijl user0X geen mogelijkheid heeft bij "hoofduser" en "user0x" te kijken?

Ondernemer in tech (oud LOQED.com, nu UpToMore.com)


  • zomertje
  • Registratie: Januari 2000
  • Laatst online: 03-02 16:28

zomertje

Barisax knorretje

Ik denk nu meer aan een cronjob die taken bijvoorbeeld als root uitvoert en later de rechten goed zet zodat de bestanden van die bepaalde user zijn.

Normaal gesproken kun je als user niet in andermans homedir, dat is dus zo'n constructie die jij wil.

het ultieme jaargetijde.... | #!/usr/bin/girl | Art prints and fun


  • Borromini
  • Registratie: Januari 2003
  • Niet online

Borromini

Mislukt misantroop

Met zomertje :). Een cronjob aanmaken (man crontab dacht ik), en in het script chmod (en indien nodig chown) gebruiken om achteraf alle rechten enzo goed te zetten :).

Got Leenucks? | Debian Bookworm x86_64 / ARM | OpenWrt: Empower your router | Blogje


  • zAo
  • Registratie: Maart 2002
  • Laatst online: 10:51

zAo

GPLv2 Fanboy

Ik heb geen kennis van php, maar is dit wat je bedoeld?

code:
1
2
3
4
5
Rechten:
/home/hoofduser/ hoofduser:user0x-groep    rwx--x--- 
/home/user0x/ user0x:hoofduser-groep       rwxr-x---

/home/hoofduser/script.php hoofduser:userx0-groep rwxr-x---



De hoofduser mag nu overal kijken en de user0x kan nu alleen het script aanroepen in de home van 'hoofduser', hij kan er niet in listen.

  • pierre-oord
  • Registratie: April 2002
  • Laatst online: 15-01 10:55
zomertje schreef op donderdag 02 februari 2006 @ 12:48:
Ik denk nu meer aan een cronjob die taken bijvoorbeeld als root uitvoert en later de rechten goed zet zodat de bestanden van die bepaalde user zijn.

Normaal gesproken kun je als user niet in andermans homedir, dat is dus zo'n constructie die jij wil.
Het script zal later aangesproken worden op deze manier:
Webserver server1 -----------ssh-----------> server2 > Script

Root rechten is natuurlijk wel een oplossing, maar als er dan *iets* misgaat op server1 kwa hacking/cracking, dan is server2 ook meteen de klos. O ja, en dit wordt geimplementeerd voor een heel scala aan servers behalve alleen "server2".

Tsja anders zou je moeten werken met een soort queue voor opdrachten en dan laten uitvoerendoor de cron. maar ik _moet_ de commando's direct uitvoeren, wachten is geen optie :(

De oplossing met het script uitvoeren als de user "user01" is nog wel het beste plan misschien en dan de directory"hoofduser' group readable maken. Echter kunnen users dan veel teveel info kopieren en downloaden uit dat account.

Er schiet me nu iets (insecures) te binnen wat ik nog kan doen: het script starten als root vanuit user "hoofduser". In visudo alleen dat script opgeven als wat mag worden geexecute als root. Het script kan dan onbeperkt alles regelen. Misschien is dat de beste oplossing.

Toch vind ik dit bestwel een tekortkoming van het user/group systeem van linux ;(

Ondernemer in tech (oud LOQED.com, nu UpToMore.com)


  • pierre-oord
  • Registratie: April 2002
  • Laatst online: 15-01 10:55
zAo schreef op donderdag 02 februari 2006 @ 12:53:
Ik heb geen kennis van php, maar is dit wat je bedoeld?

code:
1
2
3
4
5
Rechten:
/home/hoofduser/ hoofduser:user0x-groep    rwx--x--- 
/home/user0x/ user0x:hoofduser-groep       rwxr-x---

/home/hoofduser/script.php hoofduser:userx0-groep rwxr-x---



De hoofduser mag nu overal kijken en de user0x kan nu alleen het script aanroepen in de home van 'hoofduser', hij kan er niet in listen.
php heeft er niet echt mee te maken, bash zou het probleem ook hebben.
user0x staat voor: user01, user02, user03, enz.

W8 even, ik wilde gaan typen dat dit niet kon,maar volgens mij klopt het wat je zegt! Hoofduser kan overal bij, maar de usr0x kan natuurlijk niet in de andere directory's komen omdat dat niet z'n groep is! user0x kan in het geval wat jij zegt wel in "hoofduser"komen maar dat is tuurlijk zo op te lossen :D
Ik ga het zo meteen proberen!

Het is eigenljk heel logisch, maar ik zag het gewoon even niet meer!

Ondernemer in tech (oud LOQED.com, nu UpToMore.com)


  • Geuze
  • Registratie: Juli 2005
  • Laatst online: 10-04-2024
pierre-oord schreef op donderdag 02 februari 2006 @ 12:15:
Bied linux op de een of andere manier een mogelijkheid om de user "hoofduser' wel in de mappen user01, user02 toe te laten, terwijl user0X geen mogelijkheid heeft bij "hoofduser" en "user0x" te kijken?
Ja maak gebruik van groep rechten.
elke user0X in zen eigen groep hoofduser in alle groepen homedir hoofduser blijft 700 en homedirs andere users wordt 770

daarmee is eigelijk heel je probleem opgelost zonder ingewikkelde scripting work arounds te gaan toepassen

It is Good to be Bad || Battle.net tag


  • igmar
  • Registratie: April 2000
  • Laatst online: 31-01 23:50

igmar

ISO20022

Ik zou gewoon ACL's gebruiken, dat lost in een klap het gehele scala aan genoemde problemen op.

  • zAo
  • Registratie: Maart 2002
  • Laatst online: 10:51

zAo

GPLv2 Fanboy

igmar schreef op donderdag 02 februari 2006 @ 13:25:
Ik zou gewoon ACL's gebruiken, dat lost in een klap het gehele scala aan genoemde problemen op.
ACL's zijn lastig te onderhouden en niet direct zichtbaar (zit hier op AIX en SUN, kan even niet spreken voor Linux). Waarom zou je dan ACL's gaan zetten als het d.m.v. het filesystem/groepen op te lossen is?

  • Gerco
  • Registratie: Mei 2000
  • Laatst online: 06:19

Gerco

Professional Newbie

Ik gebruik ACLs om het bovengenoemde problemenscala op te lossen:

De homedirs van de users zijn eigendom van root:root (kan elke andere user/group zijn overigens). De users hebben een rwx ACL op hun homedir. De homedirs hebben bovendien allemaal een default:group:admins:rwx waardoor bestanden in de homedir van een user altijd door de admins te lezen en bewerken zijn. Het is natuurlijk wel handig om de files na plaatsing in de homedir (uitpakken) naar de user:group te chownen, aangezien de user anders de rechten op zijn files niet meer kan aanpassen.

Apache heeft alleen --x rechten op die dir, zodat de contents niet gelist kunnen worden met brakke scripts en de apache server toch bij de public_html directory kan. Dat is niet erg veilig, dat weet ik, maar het is een klein extra hobbeltje voor kwaadwillenden.

Dus:
/home/user1:
owner: root
group: root
user: rwx
group: ---
other: ---
user:user1:rwx
user:apache:--x
group:admins:rwx
default:group:admins:rwx

De user is dus geen eigenaar van zijn homedir, hij kan de rechten dus niet aanpassen. Dat is bewust gedaan, scheelt een hoop gezeur met mensen die niet weten hoe rechten werken en in hun FTP client random wat vakjes gaan aanvinken en dan opbellen dat hun website niet meer werkt.

Apache en Users hebben overigens ook alleen --x op de /home directory, daardoor kunnen ze niet zien welke andere users er allemaal zijn. Met wat gokken kunnen ze natuurlijk wel een naam raden, maar dan hebben ze nog geen toegang tot die homedir natuurlijk. Ook dat is weer zo'n klein hobbeltje.

De ACLs zijn handmatig een beetje irritant om in te stellen, maar daar heb je scripts voor nietwaar?

---

Je bereikt grotendeels hetzelfde door gebruik te maken van user private groups, het umask in te stellen zodat user en group rwx krijgen en de admin in alle user groups toe te voegen. Het enige wat mijn oplossing dan anders doet is voorkomen dat een user de rechten op zijn homedir kan aanpassen en de apache user wat strenger beperken. Als je apache niet nodig hebt en je hebt knowledgable users (if only), maakt het niet uit.

[ Voor 40% gewijzigd door Gerco op 02-02-2006 15:56 ]

- "Als ik zou willen dat je het begreep, legde ik het wel beter uit!" | All number systems are base 10!


  • pierre-oord
  • Registratie: April 2002
  • Laatst online: 15-01 10:55
Ik zorg dmv de FTP server zelf dat users geen chmod bewerkingen kunnen uitvoeren :)

Ik zit alleen met een klein probleempje nog:
code:
1
2
3
4
5
6
7
manageuser@pierre-srv:/home/game01$ touch testfile
manageuser@pierre-srv:/home/game01$ chmod 660 testfile
manageuser@pierre-srv:/home/game01$ ls -lsa testfile
0 -rw-rw----  1 manageuser manageuser 0 2006-02-03 12:39 testfile
manageuser@pierre-srv:/home/game01$ chown pierre testfile
chown: changing ownership of `testfile': Bewerking niet toegestaan
manageuser@pierre-srv:/home/game01$


Ik werk eigenlijk altijd onder root :x dan heb je die problemen niet ;)

Waarom kan een gebruiker niet rechten overdragen aan een andere gebruiker? (en er overigens zelf ook nog bijkunnen doordat de group goed staat)
Dit is nodig omdat het script wat files aanmaakt (onder user "manageuser") terwijl ik dus eigenaar van de homedir de rechten wil geven.

ACL heb ik nog nooit van gehoord zal er eens naar kijken, maar ik ben bang dat het dan moeilijker wordt dan dat het nodig is :)

edit:
Ah leuk, ik vind op google dus dat je alleen als root de eigenaar mag wijzigen. Group wijzigen mag wel :/

Moet ik nu iedere user in een _eigen_ group gaan plaatsen, zodat ze bij hun files kunnen komen? Ik denk dat dat de enige nette oplossing is?

edit2:
Maar... als ik dat doe, en de user maakt een paar files aan, dan komen die onder de rechten user:user te staan, en kan "manageuser" dus niet meer bij die files komen :/

edit3:
Ik denk dat ik de user "manageuser" dan dus alle groups ga geven die er zijn van die users.

edit4:
De manier zoals in edit3 werkt goed :) en opzich is dat ownen aan een groep enzo toch maar eenmalig.

[ Voor 33% gewijzigd door pierre-oord op 03-02-2006 14:01 ]

Ondernemer in tech (oud LOQED.com, nu UpToMore.com)

Pagina: 1