Rechten op map PROFTP

[Verwijderd]

Ik heb een PROFTPD server draaien en nu wil ik gebruikers rechten toe gaan kennen.

ik heb de map /data deze is van de gebruiker en groep "root root"
nu heb ik een berg gebruikers ( c.a. 25) die allemaal lid zijn van de groep ftp en ze hebben natuurlijk hun eigen gebruikersnaam.

Het volgende wil ik voor elkaar krijgen:

Iedereen moet in de groep FTP moet toegang krijgen tot de map /data en moet daar kunnen lezen schrijven enz enz maar ze mogen niet elkaar de mappen en bestanden wijzigen. ( dit is een probleem omdat iedereen lid is van de groep FTP)

Nu ben ik hier mee aan de slag gegaan en heb map /data van de groep FTP gemaakt en een chmod 770 gegeven. Na ik dit had gedaan kon iedereen in de groep ftp de map betreden en kon er in lezen en schrijven, maar ze konden ook elkaar de bestanden/mappen wijzigen wat ik dus niet wil.

Zelf kom ik er niet uit hoe ik dit op kan lossen want iedere user moet in dezelfde groep blijven. Na wat kijken zag ik dat je in PROFTPD ook op kon geven op welke map welke rechten van toepassing zijn met het commando <limit>

voorbeeld

code:

<Directory /data>

  <Limit ALL>
      DenyAll
    </Limit>

    <Limit CDUP PWD CWD XCWD XCUP LIST>
      AllowAll
    </Limit>

    <Limit STOR DELE STOU MKD XMKD RMD XRMD>
      AllowAll
    </Limit>

    <Limit PORT PASV>
      AllowAll
    </Limit>

    <Limit RETR>
      AllowAll
    </Limit>

  </Directory>

Ook zag ik dat PROFTPD zelf onder een gebruiker draaid en wel de gebruiker en NOBODY en groep NOBODY.
Wat ik zelf hiebij dacht is dat ik de map /data van NOBODY:NOBODY maak en de rechten op de map 750 maak dat ik daaran de rechten met limit toe ga kennen ( maar tot nu toe nog geen succes). Is dit de juiste gedachten dat als ik de map /data van NOBODY:NOBODY maak de chmod 750 geef dat chmod de rechten omzeild en doordat ik limit schrijven toesta wel kan ?

Het idee is dus dat iedereen in de groep FTP in de map /data kan schrijven en daar alleen ze eigen gemaakte bestanden + mappen kan wijzigen en verwijderen.

Of moet dit alles op een andere manier opgelost worden ? who helps me out?

[ Voor 4% gewijzigd door Verwijderd op 04-03-2005 22:24 ]

[blaataaps]

Ik heb geen idee hoe dat met proftpd werkt, maar met standaard unixpermissies kan het wel.
Als je de sticky bit op een directory toepast, en hem schrijfbaar voor iedereen maakt, mag iedereen er bestanden maken enzo, maar alleen zijn eigen bestanden verwijderen, precies wat jij wil dus (wel zorgen dat root dan owner blijft, of dat ze in ieder geval geen write-rechten van de group krijgen, want die hebben "voorrang". Dit is ook wat er bij /tmp gebeurt, iedereen mag er schrijven, maar alleen aan zn eigen bestanden zitten.

[Verwijderd]

How sticky bit is even denken ben maandag begonnen aan mijn stage en afgelopen week heel wat research gedaan op dit maar de stick bit is toch dit:

1777

dan is de 1 toch de sticky bit ?

thnx for quick response hoewel ik morgen pas kan gaan sleutelen omdat ik zo slim ben geweest me ip van thuis niet in de hosts.allow er bij te knallen

[blaataaps]

code:

bash-2.05$ mkdir test
bash-2.05$ chmod 1777 test/
bash-2.05$ ls -ld test/
drwxrwxrwt  2 henk henk  512 Mar  4 22:35 test/
bash-2.05$

Lijkt er wel op

[Verwijderd]

aha ok

zou ik mogen vragen of dit topic even mag open blijven zodat als ik morgen problemen ondervind weer even kan posten. ( sinds ik nu niets kan doen )

[pierre-oord]

Volgens mij moet je op je systeem (linux zelf) een aantal users aanmaken, in dit geval dus 25.
Je kunt daarna in proftpd de umask instellen, dit wordt zegmaar van de 777 permissies afgetrokken.
Dus:
User: lezen + schrijven = 6
Group: lezen = 4
Iedereen: lezen = 4

Dat wordt dus: 644.
De umask moet dan dus worden:
777
644
--------
133

Zorg dat de userid's die je in de proftpd configuratie file maakt overeenkomen met de userid's in het linux systeem zelf (zie /etc/passwd).

Nu wil ik even zeggen: ik ben geen expert en heb maar kort hiermee echt gewerkt met proftpd.
Nu begrijp ik alleen niet wat wat het voordeel is van wat blaataaps zegt. Het klopt dat die sticky bit daarvoor werkt zoals ik zag op google. Ik zie alleen niet in wat het verschil is met de oplossing die ik hierboven geef, en die hij geeft. Is die sticky bit eigenlijk recursive? Dus als een gebruiker een nieuwe directory aanmaakt, wordt alles daaronder dan ook sticky? Ook vraag ik me af of dit niet veel ingewikkelder is dan de standaard manier?

[Verwijderd]

pierre-oord schreef op vrijdag 04 maart 2005 @ 22:42:
Volgens mij moet je op je systeem (linux zelf) een aantal users aanmaken, in dit geval dus 25.
Je kunt daarna in proftpd de umask instellen, dit wordt zegmaar van de 777 permissies afgetrokken.
Dus:
User: lezen + schrijven = 6
Group: lezen = 4
Iedereen: lezen = 4

Dat wordt dus: 644.
De umask moet dan dus worden:
777
644
--------
133

Zorg dat de userid's die je in de proftpd configuratie file maakt overeenkomen met de userid's in het linux systeem zelf (zie /etc/passwd).

Nu wil ik even zeggen: ik ben geen expert en heb maar kort hiermee echt gewerkt met proftpd.
Nu begrijp ik alleen niet wat wat het voordeel is van wat blaataaps zegt. Het klopt dat die sticky bit daarvoor werkt zoals ik zag op google. Ik zie alleen niet in wat het verschil is met de oplossing die ik hierboven geef, en die hij geeft. Is die sticky bit eigenlijk recursive? Dus als een gebruiker een nieuwe directory aanmaakt, wordt alles daaronder dan ook sticky? Ook vraag ik me af of dit niet veel ingewikkelder is dan de standaard manier?

was ik al achter, je kan namelijk in proftp een algemen UMASK mee geven of op elke map een apperte UMASK meegeven.

022 lijkt mij wel geschikt

[pierre-oord]

Waarom wil je alle bestanden meteen executable maken? Lijkt me beetje erg onnodig, en het geeft een heel gek beeld als de list opvraagt en je ziet allemaal executable bestanden?

edit:
Ook is het weer makkelijker bestanden uit te voeren bij veiligheidslekken enzo.

[ Voor 21% gewijzigd door pierre-oord op 05-03-2005 15:56 ]

[Boudewijn]

inderdaad, dat is bloedlink.

geen x-bit meegeven dus!!!

[Verwijderd]

BoudewijnLinux schreef op zaterdag 05 maart 2005 @ 18:36:
inderdaad, dat is bloedlink.

geen x-bit meegeven dus!!!

je hebt toch een x-bit nodig op een map op er in te kunnen kijken, want met alleen read kan je de map tohc niet betreden.