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

Marcus Röckrath marcus.roeckrath at gmx.de
Do Aug 15 18:20:09 CEST 2024


Hallo Rolf,

Rolf Bensch wrote:

> schon klar. Das erklärt aber "492" nicht.

4xx lässt auf einen Systemuser schliessen, deren Nummern dynamisch vergeben 
werden, so dass sich aus der Nummer nicht auf den Namen - und damit das 
Paket - schliessen lässt.

Du hast wahrscheinlich mal ein Paket installiert gehabt, welchen einen 
Systemuser angelegt hat, welcher dann due UID 492 bekommnen hat.

Dieses Paket musst du dann später wieder deinstalliert haben, womit der 
Systemuser entfernt wurde.

Es ist halt nun nicht mehr nachvollziehbar, welchen Weg das genau genommen 
hat.

>> 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
> 
> Hier sind alle *acl* ind er Samba-Config aus "yes" gesetzt.

Weil der Kernel die Fähigkeit besitzt:

grep posix_acl_ /proc/kallsyms

>> Weiterhin gibt es in der Samba-Konfiguration noch die Option
>> SAMBA_ACL_ATTR.
> 
> Hier gibt es ein "SAMBA_ACL_XATTR = no". Darüber hinaus sehe ich im ECE
> keine Möglichkeit ACLs zu beeinflussen. Dadurch bleibt für mich die Frage
> wodurch das aktiviert wurde.

Dies würde bei yes setzen:

acl_xattr:ignore system acls = no
acl_xattr:default acl style = posix

In der Penne habe ich im Datengrab häufig Dateien mit ACLs gehabt, die 
allesamt von Win-Clients den Weg auf den Server gefunden haben.

-- 
Gruß Marcus
[eisfair-Team]



Mehr Informationen über die Mailingliste Eisfair