[Eisfair] [e64]: Gruppenverzeichnis Rechte (einschl. smb)

[Marcus Röckrath]

Hallo Rolf,

Rolf Bensch wrote:

>> Mach mal
>> 
>> getfacl /data/test
> 
>    # getfacl /data/test
>    getfacl: Removing leading '/' from absolute path names
>    # file: data/test
>    # owner: markus
>    # group: musik
>    user::rwx
>    user:492:r-x
>    group::r-x
>    mask::rwx
>    other::---
>    default:user::rwx
>    default:user:492:r-x
>    default:group::r-x
>    default:mask::r-x
>    default:other::r-x
> 
>>>     # file: ..
>>>     # owner: markus
>>>     # group: root
>>>     user::rwx
>>>     user:492:r-x
>> 
>> Wer ist der User 492?
> 
> Den gibt es hier nicht:
> 
>    # grep 492 /etc/passwd

Vielleicht gabs den mal; der Nummer nach könnte es ein Systemuser gewesen 
sein.

> Ich finde lediglich noch eine Referenz in /etc/groups:
> 
>    # grep 492 /etc/group
>    www:x:492:wwwrun
> 
> ohne dass ich das jetzt irgendwie zuordnen könnte.

Wenn du z. B. den Apachen drauf hast, ist das normal:

eisman query system-user-wwwrun
name       system-user-wwwrun
version    3.4.0
short      system-user-wwwrun - System user wwwrun and group www
date       2023-09-20
url        https://www.pack-eis.de/dl.php?l=60535/system-user-wwwrun.tar.bz2
status     stable

# grep wwwrun /var/install/packages/* | grep require
/var/install/packages/apache2:<require-package>system-user-wwwrun 
3.4.0</require-package>
/var/install/packages/roundcube:<require-package>system-user-wwwrun 
3.4.0</require-package>

>>> Jetzt noch etwas das mir das mich ganz aus dem Konzept wirft: erstelle
>>> ich das neue Verzeichnis unter /date/home/ (/home ist Link darauf),
>>> funktioniert es wie es soll.
>> 
>> Wie sieht in diesem Fall getfacl aus:
>> 
>> getfacl /data/home/test
> 
> Gerade nochmals frisch getestet: ein neu angelegtes Verzeichnis
> /data/home/test2 erhält die gleichen Rechte wie /data/test. Ich hatte
> gestern vermutlich manuell ein "setfacl -m g:musik:rwx /data/home/test2/"
> ausgeführt. Darüber haben dann Mitglieder der Gruppe "musik" auch
> Schreibzugriff. Führe ich das auch auf /data/test aus, erhalte ich das
> gleiche Ergebnis - es funktioniert. Es gibt also keinen Unterschied
> zwischen /data und /data/home (sorry wg des Durcheinanders).

Wahrscheinlich werden die ACLs auf neue Verzeichnisse vererbt.

Lösch doch mal den ACL auf data:

setfacl -b /data

> Es bleiben für mich aber 2 Fragen offen:
> 1. Ist es richtig, dass die ACL auch auf Shell-Ebene des Servers greifen?
> Ich finde es sehr verwirrend, wenn ich mich nicht mehr auf ein "ls -l"
> verlassen kann.

Das + hinter den üblichen Rechtekürzeln in der Ausgabe von ls -l zeigt dir 
an, dass ACL existieren.

> 2. Wieso ist auf dem Server plötzlich ACL aktiv und
> wirksam. Auf meinen anderen Servern ist das nicht der Fall und bewusst
> aktiviert habe ich das nicht. Ist es möglich, dass man das über einen
> Windows-Client i.V.m. Samba aktivieren kann? Wie werde ich das wieder los?
> Auch wenn das ein (fast) reiner Fileserver ist, sehe ich aktuell keine
> Notwendigkeit für ACLs.

IMHO ist ACL schon lange aktiv und kann von Anwendungen auch genutzt werden 
und muss auch nicht exlizit an- oder abgeschaltet werden.

Samba setzt in Abhängigkeit von den Fähigkeiten des Kernels:

 acl group control = yes
 force unknown acl user = yes
 inherit acls = yes
 map acl inherit = yes

Weiterhin gibt es in der Samba-Konfiguration noch die Option SAMBA_ACL_ATTR.

-- 
Gruß Marcus
[eisfair-Team]