Frage zu Rechteeingrenzung pro user

[incmc]

Hi!

Ich versuche zwei Gruppen von usern anzulegen mit unterschiedlichen Rechten. Die einen sind in ihrem Homeverzeichnis eingesperrt, die anderen nicht. Das klappt auch. Authentifizierung läuft per eigenen passwd / group file, auch ok.
Nun verstehe ich aber nicht wie die Rechte unter der Haube laufen. Laufen die User jetzt alle auf dem Account den ich in der Serverconfig mit "User" und Group festgelegt habe? Sprich was der "echte" User nicht darf, dürfen auf die virtuellen user nicht?

Die zweite Gruppe die nicht chrooted wird, soll echten root Zugriff haben. Dieser login soll aber limiert werden auf ein privates Subnetz (und wird auch ssl verschlüsselt was jetzt aber erst mal nicht wichtig ist). Ich dachte ich könnte das mit Limit LOGIN machen, jedoch sagt die Doku, dass ich dies nicht in einem Directory Block nutzen kann.
Müsste ich nicht dieser Gruppe von usern einen "echten" User zuweisen mittels "User", der root Rechte hat?

Nur wie machen...?


Gruß, incmc

[stonki]

Hi!

Nun verstehe ich aber nicht wie die Rechte unter der Haube laufen. Laufen die User jetzt alle auf dem Account den ich in der Serverconfig mit "User" und Group festgelegt habe? Sprich was der "echte" User nicht darf, dürfen auf die virtuellen user nicht?

Nein. In Deinem AuthUserFile sollte eine UID drin stehen. Damit laeuft er dann.

http://castaglia.proftpd.de/doc/contrib/ProFTPD-mini-HOWTO-AuthFiles.html
http://www.proftpd.de/index.php?id=28&language=&directive_name=user&module_id=&=OK#211

Die zweite Gruppe die nicht chrooted wird, soll echten root Zugriff haben. Dieser login soll aber limiert werden auf ein privates Subnetz (und wird auch ssl verschlüsselt was jetzt aber erst mal nicht wichtig ist). Ich dachte ich könnte das mit Limit LOGIN machen, jedoch sagt die Doku, dass ich dies nicht in einem Directory Block nutzen kann.
Müsste ich nicht dieser Gruppe von usern einen "echten" User zuweisen mittels "User", der root Rechte hat?

wieso nicht ?:
defaultroot ~ !zweite Gruppe

Deine Zugangskontrolle kannst Du auf zwei Arten sehr flexibel gestalten:

http://castaglia.proftpd.de/modules/mod_wrap-2.0.html
oder
http://castaglia.proftpd.de/modules/mod_ifsession.html


<IfGroup Gruppe2>
    <Limit Login>
DenyFromAll
Allow 192.168.0.4
</limit>
</IfGroup>

UNGETESTET

cu
stonki

[incmc]

Nein. In Deinem AuthUserFile sollte eine UID drin stehen. Damit laeuft er dann.

http://castaglia.proftpd.de/doc/contrib/ProFTPD-mini-HOWTO-AuthFiles.html
http://www.proftpd.de/index.php?id=28&language=&directive_name=user&module_id=&=OK#211

Die Seiten hatte ich schon gelesen. Also ich sehe das anders. Die uid die ich meinem  virtuellen User in meinem AuthUserFile zuweise ist ebenfalls virtuall, nicht die von einem echten System user. Wo steht das denn in der Seite oder versteh ich da was falsch?

Deine Zugangskontrolle kannst Du auf zwei Arten sehr flexibel gestalten:

http://castaglia.proftpd.de/modules/mod_wrap-2.0.html
oder
http://castaglia.proftpd.de/modules/mod_ifsession.html


<IfGroup Gruppe2>
    <Limit Login>
DenyFromAll
Allow 192.168.0.4
</limit>
</IfGroup>

UNGETESTET

Teste ich sofort :-)

Gruß, incmc

[incmc]

Also das mit IfGroup geht irgendwie gar nicht. Null Effekt. Nachdem ich jetzt seit stunden nicht weiterkomme, hoffe ich mal, dass einer hier mir das erklären kann.

Also hier mal die Config:

Code:

ServerIdent on "Ich bin bald nen ftp server"
ServerType standalone
ScoreboardFile /var/run/proftpd.scoreboard
IdentLookups off
Port 21
Umask 022
MaxInstances 20
User nobody
Group nogroup
AuthOrder mod_auth_file.c
AuthGroupFile /usr/local/etc/proftpd.group
AuthUserFile /usr/local/etc/proftpd.passwd
DefaultRoot ~ ftpusers-chroot
RequireValidShell off
PassivePorts 40000 40500
RootLogin on
UseFtpUsers off
AllowOverwrite on
AllowStoreRestart on
AllowRetrieveRestart on
LogFormat tolleslog "%t %U %h '%m %f' %T"
ExtendedLog /var/log/proftpd-transfers.log read,write tolleslog


<IfGroup ftpusers-free>
    <Limit Login>
        Deny from all
        Allow 192.168.100.30
    </Limit>
</IfGroup>

<IfGroup ftpusers-free>
    <Directory ~>
        <Limit WRITE>
            DenyAll
        </Limit>
    </Directory>
    <Directory ~/upload/*>
        <Limit ALL>
            AllowAll
        </Limit>
    </Directory>
</IfGroup>

Hier noch die proftpd.group und proftpd.passwd

Code:

ftpusers-chroot:x:65533:ugauga
ftpusers-free:x:0:root

Code:

root:blabla.:0:0::/:/sbin/nologin
ugauga:blabla.:65534:65533::/home/ftpusers/ugauga:/sbin/nologin

So, und jetzt bin ich mal gespannt, ich werde langsam echt wahnsinnig.

Gruß, Jochen

[stonki]

Nein. In Deinem AuthUserFile sollte eine UID drin stehen. Damit laeuft er dann.

http://castaglia.proftpd.de/doc/contrib/ProFTPD-mini-HOWTO-AuthFiles.html
http://www.proftpd.de/index.php?id=28&language=&directive_name=user&module_id=&=OK#211

Die Seiten hatte ich schon gelesen. Also ich sehe das anders. Die uid die ich meinem  virtuellen User in meinem AuthUserFile zuweise ist ebenfalls virtuall, nicht die von einem echten System user. Wo steht das denn in der Seite oder versteh ich da was falsch?

Also ich kenne das nur von mod_sql, aber das sollte identisch sein. die UID und GID die Du gibst ist entscheidend. OB dafuer ein User in /etc/passwd existiert ist dann nur noch Schoenheit, also z.B. dass fuer die UID 500 (oder 33333) der User Stonki angezeigt wird oder nicht. Intern wird eh nur die numerische UID ausgewertet.

cu
stonki

[incmc]

ok, aber was ist mit dem IfGroup? Wieso zur Hölle geht das denn nicht :-( ?

Gruß, incmc

[stonki]

ok, aber was ist mit dem IfGroup? Wieso zur Hölle geht das denn nicht :-( ?

Gruß, incmc

tscha, das weiss ich leider auch nicht. Erstelle doch mal eine Gruppe fuer die GID und probiere es dann noch mal.

cu
stonki

[incmc]

Also jetzt einmal Schritt für Schritt. Ich glaub ich habe da ein Verständnisproblem.

Ich habe gerader daher erst einmal die Authentifizierung erst einmal wieder auf mod_auth_unix.c gestetzt und zwar ausschließlich. Gut, also nur reale Accounts. Konfig sieht dann so aus

Code:

ServerIdent on "Serverbla"
ServerType standalone
ScoreboardFile /var/run/proftpd.scoreboard
IdentLookups off
Port 21
Umask 022
MaxInstances 20
User nobody
Group nogroup
AuthOrder mod_auth_unix.c
RequireValidShell off
PassivePorts 40000 40020
RootLogin on
UseFtpUsers off
AllowOverwrite on
AllowStoreRestart on
AllowRetrieveRestart on
LogFormat tolleslog "%t %U %h '%m %f' %T"
ExtendedLog /var/log/proftpd-transfers.log read,write tolleslog


<IfGroup wheel>
    <Limit Login>
        Deny from all
        Allow 192.168.10.3
    </Limit>
</IfGroup>

<IfGroup !wheel>
    <Directory ~>
        <Limit WRITE>
            DenyAll
        </Limit>
    </Directory>
    <Directory ~/upload>
        <Limit ALL>
            AllowAll
        </Limit>
    </Directory>
</IfGroup>

Dann habe ich einen user "test" angelegt der nur Mitglied seiner eigenen Gruppe "test" ist. Logge ich mich nun ein unter User Test sollte der nach obigen Regeln nur in seinem "upload" Verzeichnis welches ich vorher angelegt habe, schreiben dürfen. Er kann aber nirgends schreiben. Permission denied selbst beim neuen Unterordner anlegen. Woran liegt das? Zudem kann ich mich auch als "root" von jeglicher IP einloggen, nicht nur con "192.168.10.3", also klappt auch das nicht. Das verstehe ich nicht. Wenn das klappt, dann mal weiter mit virtuellen usern überlegen... :-)

Gruß, incmc

[stonki]

Also jetzt einmal Schritt für Schritt. Ich glaub ich habe da ein Verständnisproblem.

Code:

<IfGroup wheel>
    <Limit Login>
        Deny from all
        Allow 192.168.10.3
    </Limit>
</IfGroup>

<IfGroup !wheel>
    <Directory ~>
        <Limit WRITE>
            DenyAll
        </Limit>
    </Directory>
    <Directory ~/upload>
        <Limit ALL>
            AllowAll
        </Limit>
    </Directory>
</IfGroup>

Dann habe ich einen user "test" angelegt der nur Mitglied seiner eigenen Gruppe "test" ist. Logge ich mich nun ein unter User Test sollte der nach obigen Regeln nur in seinem "upload" Verzeichnis welches ich vorher angelegt habe, schreiben dürfen. Er kann aber nirgends schreiben. Permission denied selbst beim neuen Unterordner anlegen. Woran liegt das? Zudem kann ich mich auch als "root" von jeglicher IP einloggen, nicht nur con "192.168.10.3", also klappt auch das nicht. Das verstehe ich nicht. Wenn das klappt, dann mal weiter mit virtuellen usern überlegen... :-)

Gruß, incmc

sowas teste ich sonst auch immer am Beispiel aus.. Mach aber mal:

1) <LIMIT WRITE> Anstatt <LIMIT ALL>
2)  ist root denn Mitglied der Gruppe wheel ?

cu
stonki

[incmc]

sowas teste ich sonst auch immer am Beispiel aus.. Mach aber mal:

1) <LIMIT WRITE> Anstatt <LIMIT ALL>
2)  ist root denn Mitglied der Gruppe wheel ?

cu
stonki

1) nichts, permission denied. Write ist ja auch in All enhalten
2) siehe code:

Code:

# cat /etc/group
# $FreeBSD: src/etc/group,v 1.19.2.3 2002/06/30 17:57:17 des Exp $
#
wheel:*:0:root,status
daemon:*:1:daemon
kmem:*:2:root
sys:*:3:root
tty:*:4:root
operator:*:5:root
mail:*:6:
bin:*:7:
...
,,,

Es muss irgendwie an dem IfGroup liegen. Denn, kommentiere ich den ersten IfGroup Block aus, sprich deaktiviere ich ihn, dann funktioniert das einloggen (nun sämtlicher user) wirklich nur noch von der eingetragenen IP. Komisch. Hat denn keiner hier Erfahrung mit IfGroup?

Gruß, Jochen

[stonki]

1) nichts, permission denied. Write ist ja auch in All enhalten

Ja, ALL hat aber eine NIEDRIGE Prioritaet !


Sonst frage mal in der ML nach.

cu
stonki

[incmc]

Also heisst das, wenn ich mit einer gewisssen Priorität eine Regel setzte, kann ich sie nur durch einer wieder aufheben, die mindestens von selbiger Priorität ist?

Wenn du folgende List meinst,.. proftp-user@lists.sourceforge.net, das habe ich schon getan, aber bisher keine Antwort. Ich seh schon ich bleib auf dem Problem hängen. Ich habe auch eine mal an TJ geschrieben, also demjenigen der auf der Seite von mod_ifsession als Ansprechpartner steht.

Gruß, incmc

[incmc]

Ich Vogel hatte die Rechte der Ordner im Unix File System falsch gesetzt :-9
Jetzt funktioniert der untere IfGroup Block wie er soll. Aber der erste immer noch nicht, User der Gruppe wheel können sich weiterhin einloggen von wo sie wollen. Ich habe mal DenyAll als einziges in dessen Limit Login Block geschrieben, kein Effekt... Komisch.

[incmc]

Soweit läuft jetzt alles. Die Geschichte mit ifsession ist jedoch anscheinend nicht ganz ausgereift. Manche Sachen lassen sich innerhalb dessen Anweisungen einfach nicht anwenden. Letztes Bsp.

Code:

<ifuser bla>
    dirfakeuser on
    dirfakegroup on
    <limit site_chmod>
        denyall
    </limit>
</ifuser>

Dies beachtet dann einfach nicht die Anweisung "dirfakegroup on", also kein Effekt. Setze ich aber eine zweite "ifuser" Anweisung untendrunter wo nur noch einmal "dirfakegroup" drinsteht, DANN geht es.

Code:

<ifuser bla>
    dirfakeuser on
    <limit site_chmod>
        denyall
    </limit>
</ifuser>

<ifuser bla>
dirfakegroup on
</ifgroup>

Also da scheint das mit ifsession aber noch nicht ausgereift zu sein. Hat jemand ähnliche Erfahrungen hier?


So, pennen. Gruß, incmc