Groep rechten geven om te chmod'den

[dtech]

Hallo,

normaal gesproken heeft enkel de owner van een file (en root natuurlijk) rechten om een file te chmod'den. Is het mogelijk om de groep ook rechten daarvoor te geven?

Zelfde vraag eigenlijk voor chown, maar die kansen schat ik wat lager in omdat alleen root volgens mij mag chown'en.

Ik heb wel geprobeerd te googlen, maar je wordt simpelweg overspoeld door "simpele" vragen over chmod en rechten

[Teckna]

sudo maar wil je dit wel? je kan bijna gewoon net zo goed deze users su rechten geven.

[dtech]

Sudo wil ik dus inderdaad niet, dat is effectief hetzelfde als root rechten geven.

Net nog bedacht dat het misschien met een chroot constructie wel zou kunnen, maar dat is veel te ingewikkeld voor de gebruikers. Die willen gewoon in hun SFTP client rechtmuisknop->rechten aanpassen kunnen gebruiken...

edit:

Waar ik ook net aan dacht: er is al een scriptje dat de rechten goed zet, met suexec kan je dat dan door willekeurige gebruikers als root uit laten voeren... Moet het alleen heel goed dichtgetimmerd worden... (ook tegen fouten van gebruikers)

[ Voor 30% gewijzigd door dtech op 10-01-2011 16:37 ]

[Onno]

Afhankelijk van je omgeving zou je POSIX of NFSv4 ACL's kunnen gebruiken.

[lordgandalf]

je kunt sudo limiterenn voor chown en chmod en dan zelfs volgens mij voor bepaalde flags

[CAPSLOCK2000]

Gebruik sudo en beperk het op pad en op flags.
Eigenlijk wil je dit echt niet.
Het gaat best lastig worden om te voorkomen dat iemand z'n eigen BASH upload, en die vervolgens het recht geeft om als root te draaien. Dan heeft die gebruiker alsnog een volledige rootshell.
Ik zeg niet dat het volkomen onmogelijk is, maar let goed op.

[jan99999]

Bij samba kun je in de config file aangeven, dat als er een file of dir in de share gezet word dat iedereen dit kan bewerken.
Misschien heeft SFTP dit ook.

[dtech]

@ndeleeuw

Ik heb er even ingekeken en er is inderdaad vrij grondige configuratie van sudo mogelijk, veel meer dan ik dacht. Daar ga ik zeker even op door. Gebruikers kunnen dan alsnog niet hun SFTP client gebruiken maar misschien is dat op te lossen met een wrapper rond de chown binarie (die dan alleen voor "normale" users gebruikt zou worden, niet voor mensen die nu al root rechten hebben of systeemprocessen.

@jan99999
Samba is wel wat anders dan SFTP. Eigenschap van SFTP is dat het eigenlijk maar een dun laagje bovenop SSH is en dat je dus altijd als "normale" user inlogt

@CAPSLOCK2000

Als je verbiedt dat de setuid flag wordt gezet is dat niet mogelijk om te doen. Dan execute je namelijk altijd een file als de ingelogde gebruiker.

[deadinspace]

Waarom wil je dit precies?

En let met chown/chmod toestaan via sudo heel erg op dat je dit goed doet, want anders introduceer je bergen subtiele security issues

[begintmeta]

Kan je niet toch iets beginnen bet openssh/chroot? Of met een andere STP-host zoals proftpd?

[ Voor 38% gewijzigd door begintmeta op 11-01-2011 08:30 ]

[dtech]

@begintmeta
Dat is een optie, maar ik hoopte dat het "simpeler" op te lossen was (als in: een workaround/hack achtig iets)

@deadinspace

Ik beheer een server waar een aantal groeperingen een stukje webruimte op een subdomein hebben. Vaak werken twee of drie mensen aan een website. Niveau is vaak niet meer dan "ik weet hoe ik wordpress kan installeren!".
Ze hebben allemaal een inlog (gekoppeld met een ander systeem) op de server en kunnen dus SSH'en en SFTP'en, dat is in principe ook wat we willen.

Om te voorkomen dat mensen elkaars files gaan zitten lezen (of schrijven zelfs) staat de eigenaar van de files op www-data en de groep waar de website van is, other rights staan op 0.

Duidelijk zo?

Ik weet dat het niet de ideale situatie is, maar het is historisch zo gegroeid (bovendien zijn we allemaal leken). Als debian squeeze uitkomt gaan we hem overzetten en een aantal configuraties flink aanpassen, waaronder die van apache. Plan is dan om voor elke vhost een eigen user aan te maken. Dat zou het ook eventueel mogelijk/makkelijk maken om een aparte sftp server op te zetten. gechrootte sftp server is ook een idee.

[deadinspace]

dtech schreef op woensdag 12 januari 2011 @ 13:34:
Duidelijk zo?

Niet helemaal. Heeft elke gebruiker zijn eigen system user (en group), en is er een group voor elke website waar dan de juiste users lid van zijn? Of is er één system user per website, waar verschillende mensen mee inloggen?

[dtech]

Elke gebruiker heeft één NIS user en er is voor elke website een groep waar de juiste users van lid zijn.

Als er maar één user zou zijn was het simpel: user groepsnaam en groep www-data. Daarvoor zouden we het systeem om moeten gooien. (maar het is een mogelijkheid die we nu aan het onderzoeken zijn)

[ Voor 50% gewijzigd door dtech op 12-01-2011 16:40 ]

[CAPSLOCK2000]

Volgens mij ben je verkeerd bezig. Er is geen eenvoudig oplossing voor je probleem die gebruikersvriendelijk en veilig is. Mensen vanuit hun (s)ftp client met rechten laten klooien is ook niet erg verstandig.

Mijn quick-fix zou er zo uitzien.

1. Maak voor iedere website een aparte ontwikkel-directory.
De betrokken gebruikers krijgen hierin volledige rechten.

2. Schrijf een scriptje dat alles vanuit een ontwikkel-directory kopieert naar de productie-directory.
Laat dit scriptje ook de rechten aanpassen.

[dtech]

@topic

Ik ben het nu aan het implementeren door chmod te wrappen in een scriptje dat een controle doet op de groep en het alleen aanpast als de gebruiker in de groep zit. Een beetje lelijk natuurlijk maar het is (als het goed is) maar een tijdelijke oplossing

@capslock2000

Je mist het hele probleem. Het enige wat gebruikers willen kunnen in het schrijfbaar maken van files. In de documentatie staat dan iets als "druk met de rechtermuisknop op je file in de FTP client en druk op het vinkje schrijven bij user". chmod'den vanuit een SFTP client is niet onveiliger dan via SSH en gebruikers mogen het alleen doen bij hun eigen files (waarmee ze dus alleen hun eigen files in gevaar zouden kunnen brengen)

Jij suggereert een andere structuur die een boel dingen veranderd. Dat kan echter andere problemen met zich mee brengen en sowieso moeten gebruikers dan iets nieuws aanleren. Als dat toch moet doe ik het liever gelijk goed.

Bovendien is het probleem dus niet "de rechten" in het algemeen, die staan in principe al goed. Het probleem is welke files schrijfbaar moeten zijn en welke niet, en dat is gewoon niet automatisch door een scriptje te bepalen, aangezien de gebruiker zal moeten aangeven welke files dat zijn.

[begintmeta]

dtech schreef op woensdag 12 januari 2011 @ 16:38:
Elke gebruiker heeft één NIS user en er is voor elke website een groep waar de juiste users van lid zijn.

Als er maar één user zou zijn was het simpel: user groepsnaam en groep www-data. Daarvoor zouden we het systeem om moeten gooien. (maar het is een mogelijkheid die we nu aan het onderzoeken zijn)

Zou het een optie zijn om de http-daemon rechten te geven voor de website-groepen? Dan heb je geen 'www-data'-groepsrechten nodig op de bestanden van de diverse sites, en kan je gewoon de user- en groepsrechten gebruiken.

[ Voor 11% gewijzigd door begintmeta op 12-01-2011 21:46 ]

[deadinspace]

dtech schreef op woensdag 12 januari 2011 @ 16:38:
Elke gebruiker heeft één NIS user en er is voor elke website een groep waar de juiste users van lid zijn.

Dan raad ik aan om de webroot r-xrws--- van www-data:website te maken (waar website de group van de website in kwestie is).

Vervolgens is het wel wenselijk als alle nieuw aangemaakte files en directories g+w worden. Als dat standaard niet het geval is, dan moet je dat instellen daar waar de files aangemaakt worden. Op de Unix commandline gaat dat met umask, voor winscp oid zul je dat zelf moeten uitzoeken.

Daarbovenop zou je een chmod -R g+w kunnen cronnen om te zorgen dat het regelmatig goedgezet wordt. (niet ideaal, maar dit is een geval waar de Unix permissies helaas niet perfect in voorzien)

Verder kun je misschien nog iets met POSIX ACLs (maar da's meer een gok dan wat anders )

dtech schreef op woensdag 12 januari 2011 @ 21:36:
Ik ben het nu aan het implementeren door chmod te wrappen in een scriptje dat een controle doet op de groep en het alleen aanpast als de gebruiker in de groep zit. Een beetje lelijk natuurlijk maar het is (als het goed is) maar een tijdelijke oplossing

Dat zou ik afraden. Het is tricky om dat soort dingen goed te krijgen. Als je het niet goed doet, dan is de kans groot dat iets op je systeem je gewrapte chmod niet zo tof vindt (even er van uitgaand dat je hem system-wide installeert), en de potentie voor security holes is groot.

[ Voor 25% gewijzigd door deadinspace op 12-01-2011 23:06 ]

[dtech]

Ik heb naar ACL's gekeken, maar ik denk helaas dat dat niet genoeg is. Er is niet (zoals op Windows) een change ownership permission, enkel kun je als het ware extra users of groups toevoegen. Het enige wat ik dan zou kunnen bedenken is om alle users van een groep aan elke file toe te voegen, maar handig is anders (het moet immers system-wide herhaalt worden als de samenstelling van de groep veranderd)

deadinspace schreef op woensdag 12 januari 2011 @ 23:03:
[...]

Dan raad ik aan om de webroot r-xrws--- van www-data:website te maken (waar website de group van de website in kwestie is).

Vervolgens is het wel wenselijk als alle nieuw aangemaakte files en directories g+w worden. Als dat standaard niet het geval is, dan moet je dat instellen daar waar de files aangemaakt worden. Op de Unix commandline gaat dat met umask, voor winscp oid zul je dat zelf moeten uitzoeken.

Dat is allebei dus al het geval. umask staat op 207. dus standaard zijn files r-xrwx---. user is www-data en groep is website groep. Dat laatste heb ik overigens al meerdere malen gemeld.

waar het nou juist om gaat is dat liever niet alle files user-writable (door www-data dus) worden.

Dat zou ik afraden. Het is tricky om dat soort dingen goed te krijgen. Als je het niet goed doet, dan is de kans groot dat iets op je systeem je gewrapte chmod niet zo tof vindt (even er van uitgaand dat je hem system-wide installeert), en de potentie voor security holes is groot.

Daar heb ik aan gedacht. De grap is dat ik het denk goed te krijgen door een extra map (/usr/local/bin/nisonly) aan het path van nis-users waardoor die "chmod" te voorkeur krijgt boven de echte chmod.
Dat werkt allen niet als de implementatie van SFTP direct de binary gebruikt i.p.v. het path doorzoekt, maar dan kunnen de users het i.i.g. nog via SSH.

"Algoritme" is als volgt:

code:

if
  (argumenten die buiten script niet aankan)
  OR
  (user heeft root rechter)
  then
    voer chmod uit met oorspronkelijke argumenten
endif

for (elk bestand in de parameters)
  if(isdir AND user zit in groep van bestand AND -R parameter)
    chmod dir als root
    ga recursief dit script weer in

  else if (user zit in groep van bestand)
    chmod file als root

  else
    chmod file als oorspronkelijke user (geef dus eigenlijk de chmod foutmelding weer)

endfor

Ben benieuwd of het gaat werken als het af is.

[ Voor 3% gewijzigd door dtech op 13-01-2011 01:07 ]

[dtech]

begintmeta schreef op woensdag 12 januari 2011 @ 21:44:
[...]

Zou het een optie zijn om de http-daemon rechten te geven voor de website-groepen? Dan heb je geen 'www-data'-groepsrechten nodig op de bestanden van de diverse sites, en kan je gewoon de user- en groepsrechten gebruiken.

2 problemen daarmee:
1. Groepen wil je altijd -w rechten geven omdat ze hun eigen files moeten kunnen aanpassen. Dan kan je net zo goet de user gewoon op www-data laten staan en 770 chmodden
2. www-data is een lokale user, de groep is een nis-groep

[deadinspace]

dtech schreef op donderdag 13 januari 2011 @ 01:04:
Dat is allebei dus al het geval. umask staat op 207. dus standaard zijn files r-xrwx---. user is www-data en groep is website groep. Dat laatste heb ik overigens al meerdere malen gemeld.

waar het nou juist om gaat is dat liever niet alle files user-writable (door www-data dus) worden.

Je begrijpt me verkeerd; ik had het alleen over de permissies op de webroot, niet op die van de files er in. Files die aangemaakt worden door gebruikers krijgen gewoon die gebruiker als owner, dus niet www-data.

De truuk is de setgid bit op de webroot (die heb je denk ik over het hoofd gezien, het valt ook niet goed op als ik mijn eigen post zo teruglees), die ervoor zorgt dat alle files en directories de website-groep erven.

De umask van je gebruikers zal dan overigens 002 moeten zijn, zodat ze er zelf bij kunnen en Apache de files kan lezen.

Daar heb ik aan gedacht. De grap is dat ik het denk goed te krijgen door een extra map (/usr/local/bin/nisonly) aan het path van nis-users waardoor die "chmod" te voorkeur krijgt boven de echte chmod.

Ja, zorgen dat de aangepaste chmod alleen in het pad van die gebruikers belandt zorgt er in ieder geval voor dat je systeem er niet van over de zeik gaat, maar potentiele security issues blijven

Dat werkt allen niet als de implementatie van SFTP direct de binary gebruikt i.p.v. het path doorzoekt, [...]

Oh, had je daar op gehoopt? Ik kan je garanderen dat dat niet werkt namelijk; sftp-server zal direct de chmod() systemcall gebruiken, niet het chmod commando.

[dtech]

deadinspace schreef op donderdag 13 januari 2011 @ 10:48:
[...]

Je begrijpt me verkeerd; ik had het alleen over de permissies op de webroot, niet op die van de files er in. Files die aangemaakt worden door gebruikers krijgen gewoon die gebruiker als owner, dus niet www-data.

Dat is een gedeeltelijke oplossing inderdaad, maar heeft als nadeel dat nog steeds slechts één van de gebruikers de files chmod-rechten mag editen. Het is inderdaad een simpele oplossing

De truuk is de setgid bit op de webroot (die heb je denk ik over het hoofd gezien, het valt ook niet goed op als ik mijn eigen post zo teruglees), die ervoor zorgt dat alle files en directories de website-groep erven.

Die staat dus al

[...]

Ja, zorgen dat de aangepaste chmod alleen in het pad van die gebruikers belandt zorgt er in ieder geval voor dat je systeem er niet van over de zeik gaat, maar potentiele security issues blijven

Uit pure interesse ga ik het scriptje afmaken en dan eens kijken of er inderdaad issues mee zijn.

[...]

Oh, had je daar op gehoopt? Ik kan je garanderen dat dat niet werkt namelijk; sftp-server zal direct de chmod() systemcall gebruiken, niet het chmod commando.

Dat is wel jammer. Ik heb het inmiddels zo ingesteld als jij suggereerd (dus alle files onder de webroot zijn van één user die dus rechten heeft) en zodra de configuratie herzien wordt gaat er een aparte user komen voor elke website met die rechten.

[ Voor 0% gewijzigd door dtech op 15-01-2011 01:13 . Reden: verduidelijking zie onderstaande post ]

[deadinspace]

dtech schreef op donderdag 13 januari 2011 @ 14:08:
Dat is een gedeeltelijke oplossing inderdaad, maar heeft als nadeel dat nog steeds slechts één van de gebruikers de files mag editen.

Nee, via de group-rechten (icm setgid bit en umask) kunnen alle users in die group die files editen.

[dtech]

Klopt, ik bedoelde de files chmod-waarden editen.

[Anoniem: 26306]

Even een vraagje tussendoor: Waarom moeten gebruikers een file kunnen chmodden? Kun je niet gewoon beter de directory van de juiste groep maken en chmodden naar 2775 of 2770?

Je omschrijft alleen een deeloplossing die je zelf hebt bedacht, beschrijf eens de hele situatie? Waarom moeten er meerdere gebruikers en/of groepen kunnen chmodden?

[dtech]

Lees deze post.

[Anoniem: 26306]

Ok, dan is het simpel. Voor alle bestanden geldt dan dat de owner gewoon de gebruiker moet zijn, en de group www-data. Waar www-data moet kunnen schrijven chmod je de directory naar 2770, waar www-data alleen hoeft te kunnen lezen 2750.

Als een gebruiker een directory/file aanmaakt binnen zo'n directory dan wordt de group automatisch ook www-data en zijn de rechten zodanig dat www-data er kan lezen (en schrijven waar nodig).

Van de huidige situatie moet je gewoon zo snel mogelijk af.

[dtech]

Er zijn dus meerdere mensen die de website ontwikkelen. Vandaar dat de groep een bepaalde groep moet zijn. Dit kan dus niet www-data (groep) zijn.
Als gevolg daarvan moet de user www-data zijn.

Met ACL kan je wel meerdere users specificeren, maar als de groep-members veranderen moet dat dus via een scriptje doorgevoert worden op alle files, niet ideaal dus.

Zoals ik al eerder zei heb ik het nu opgelost door de root van een website www-data:groepsnaam r-xrwx--- te maken en de files/mappen erin "een-user":groepsnaam rwxrwxr-x (x niet voor normale bestanden).

Hierdoor kan "een-user" files other-writable maken (hij mag immers zijn eigen files chmodden). Doordat de root echter enkel door www-data en de groep te lezen is kunnen nog steeds enkel www-data en de leden van de groep erbij.

[begintmeta]

Wat ik eerder bedoelde (maar 't was meer een soort opwellende gedachte, geen idee of het wat uit zou maken) is om verschillende httpd's te starten met verschillende u/g-id's Je kan in principe een algemene httpd de requests laten doorverwijzen naar de juiste httpd.

Maar goed, ik weet denk ik gewoon ook niet hoe de situatie is en wat je wil

[DutchNutcase]

dtech schreef op zaterdag 15 januari 2011 @ 13:00:
Er zijn dus meerdere mensen die de website ontwikkelen. Vandaar dat de groep een bepaalde groep moet zijn. Dit kan dus niet www-data (groep) zijn.
Als gevolg daarvan moet de user www-data zijn.

Met ACL kan je wel meerdere users specificeren, maar als de groep-members veranderen moet dat dus via een scriptje doorgevoert worden op alle files, niet ideaal dus.

Zoals ik al eerder zei heb ik het nu opgelost door de root van een website www-data:groepsnaam r-xrwx--- te maken en de files/mappen erin "een-user":groepsnaam rwxrwxr-x (x niet voor normale bestanden).

Hierdoor kan "een-user" files other-writable maken (hij mag immers zijn eigen files chmodden). Doordat de root echter enkel door www-data en de groep te lezen is kunnen nog steeds enkel www-data en de leden van de groep erbij.

Met ACL kun je ook groepen specificeren. Je zou dan de boel op www-data:www-data chown'en en ACL's toevoegen (met setfacl) voor zelf aangemaakte groepen, waar je vervolgens de specifieke gebruikers instopt. Dit is denk ik de netste manier om het te doen. En als je de defaults goed zet worden alle nieuwe bestanden in de directory ook gelijk met de juiste permissies en ACL's aangemaakt.

[dtech]

begintmeta schreef op zaterdag 15 januari 2011 @ 13:25:
Wat ik eerder bedoelde (maar 't was meer een soort opwellende gedachte, geen idee of het wat uit zou maken) is om verschillende httpd's te starten met verschillende u/g-id's Je kan in principe een algemene httpd de requests laten doorverwijzen naar de juiste httpd.

Maar goed, ik weet denk ik gewoon ook niet hoe de situatie is en wat je wil

Dat gaat gebeuren bij de upgrade naar Debian 6.0 squeeze Het is iets wat we zeker willen maar als je dan toch de configuratie omgooit moet je het gewoon gelijk goed doen.

DutchNutcase schreef op zaterdag 15 januari 2011 @ 13:51:
[...]


Met ACL kun je ook groepen specificeren. Je zou dan de boel op www-data:www-data chown'en en ACL's toevoegen (met setfacl) voor zelf aangemaakte groepen, waar je vervolgens de specifieke gebruikers instopt. Dit is denk ik de netste manier om het te doen. En als je de defaults goed zet worden alle nieuwe bestanden in de directory ook gelijk met de juiste permissies en ACL's aangemaakt.

Leuk en aardig, maar je krijgt er nog steeds niet de gewenste situatie mee:
1. www-data moet alle bestanden/mappen kunnen lezen
2. Groep moet alle bestanden/mappen kunnen lezen en schrijven
3. Alle mensen uit een groep moeten kunnen specificeren welke bestanden schrijfbaar zijn door www-data.

Sowieso is www-data:www-data modden met ACL's een beetje raar: als het goed is zit er in de www-data groep altijd maar één user (www-data) dus gebruik je gewoon een veld (standaard groep) niet.

[Olaf van der Spek]

Is world (xx6 of xx7) access geen optie?
Met ACLs is het eenvoudig user www-data lees en schrijfrechten te geven waar nodig. Maar of dat via een SFTP client kan weet ik niet.

[Klaphekje]

Dat gaat gebeuren bij de upgrade naar Debian 6.0 squeeze Het is iets wat we zeker willen maar als je dan toch de configuratie omgooit moet je het gewoon gelijkgoed doen.

Is het dan niet net zo makkelijk om dat nu al te doen? Zoek voor FCGI en Suexec hiermee kan jij je probleem oplossen, ook voor de ftp. "Klein beetje info"

(Gebaseerd op eigen ervaring, ik ben geen professionele hoster oid )

[ Voor 8% gewijzigd door Klaphekje op 30-01-2011 13:26 ]