zugriffsrechte

[a-jay]

Das darf aber in dem Fall wo ein File explizit mit 0644 angelegt ist nicht sein. Du hast wohl das Recht in das Verzeichnis zu schreiben, aber nicht auf die so angelegte Datei.
Erstell mal als root eine Datei in /volume1/public und setz die Rechte auf 0644. Dann versuche die Datei als ein Benutzer der auf /volume1/public Schreibrechte hat zu löschen. Das darf nicht klappen!

Dateisystem-Berechtigungen sind aber von Freigabe(Share-)Berechtigungen getrennt zu sehen. Wenn ein am PC angemeldeter User_1 über das Netzwerkprotokoll (Explorer) auf die DS zugreift, ist dieser nicht identisch mit dem User_1 , der auf der DS eingerichtet ist.

Es ist doch der Fileserver-(SMB-)Prozess, der mit seinen Berechtigungen letztendlich auf die Datei zugreift. Und der sieht nur nach den Share-Berechtigungen, um Zugriff zu erlauben oder zu verbieten.

So sehe ich das jedenfalls.

A-Jay

 

[jahlives]

Es ist doch der Fileserver-(SMB-)Prozess, der mit seinen Berechtigungen letztendlich auf die Datei zugreift. Und der sieht nur nach den Share-Berechtigungen, um Zugriff zu erlauben oder zu verbieten.

Der smb Prozess der auf die Dateien zugreift, sollte eigentlich unter dem jeweiligen angemeldeten User laufen und damit auch dessen Rechte haben.
Du kannst mittels smbpasswd keine Benutzer für Samba anlegen, wenn sie nicht auch lokal auf dem System existieren.

 

[a-jay]

Der smb Prozess der auf die Dateien zugreift, sollte eigentlich unter dem jeweiligen angemeldeten User laufen und damit auch dessen Rechte haben.
Du kannst mittels smbpasswd keine Benutzer für Samba anlegen, wenn sie nicht auch lokal auf dem System existieren.

Läuft den je Benutzer, der über's Netzwerk auf die DS-Shares zugreift, ein SMB-Prozess? (Linux ist schon so viele Jahre her... )

 

[jahlives]

Läuft den je Benutzer, der über's Netzwerk auf die DS-Shares zugreift, ein SMB-Prozess? (Linux ist schon so viele Jahre her... )

Jop so sollte es sein. Ich kann es jetzt gerade ned testen, werde das aber zu Hause machen und berichten.

 

[mr. winterbottom]

Das darf aber in dem Fall wo ein File explizit mit 0644 angelegt ist nicht sein. Du hast wohl das Recht in das Verzeichnis zu schreiben, aber nicht auf die so angelegte Datei.
Erstell mal als root eine Datei in /volume1/public und setz die Rechte auf 0644. Dann versuche die Datei als ein Benutzer der auf /volume1/public Schreibrechte hat zu löschen. Das darf nicht klappen!

Der Wahnsinn lässt grüssen.
Genau so kenne ich das auch aber das rot markierte funktioniert auch nicht. Das funktioniert - umgekehrt gesprochen.
Ich kann alles löschen Rechte haben KEINE funktion.
Nach wie vor kann jeder alles löschen ganz gleich wer die Datei/Ordner erstellt hat. Das funktioniert gar bei einem von root mit 700 erstelltem Ordner.

Ich glaube nicht mehr an das gute

In meiner Verzweifelung habe ich sogar am NB Win XP prof. installiert. Alles beim alten.

mr. winterbottom

 

[jahlives]

Also der Userprozess smb von Samba läuft definitiv unter dem angemeldeten Benutzer.
@mr.winterbottom
Du hast geschrieben, dass du den ipkg Samba verwendest. Bist du auf 100% sicher, dass dieser läuft? Prüfe das mal folgendermassen und poste die Ausgabe hiervon

$ ps | grep smbd

Gruss

tobi

 

[mr. winterbottom]

hi,

mir platzt gleich mei Hirn


DiskStation> ps | grep smbd
2197 root 2756 S /opt/sbin/smbd -D --configfile=/opt/etc/samba/smb.con
2214 root 1136 S /opt/sbin/smbd -D --configfile=/opt/etc/samba/smb.con
2337 root 3200 S /opt/sbin/smbd -D --configfile=/opt/etc/samba/smb.con
2339 root 3392 S /opt/sbin/smbd -D --configfile=/opt/etc/samba/smb.con
2346 root 212 S grep smbd


mr. winterbottom

 

[jahlives]

hi,

mir platzt gleich mei Hirn


DiskStation> ps | grep smbd
2197 root 2756 S /opt/sbin/smbd -D --configfile=/opt/etc/samba/smb.con
2214 root 1136 S /opt/sbin/smbd -D --configfile=/opt/etc/samba/smb.con
2337 root 3200 S /opt/sbin/smbd -D --configfile=/opt/etc/samba/smb.con
2339 root 3392 S /opt/sbin/smbd -D --configfile=/opt/etc/samba/smb.con
2346 root 212 S grep smbd


mr. winterbottom

Das ist soweit schon okay so. Wenn ein angemeldeter User kommt wird der Root Dämon eine smb Instanz starten unter den Rechten des angemeldeten Users. Am besten siehst du das wenn du auf einer Shell top oder htop anwirfst und dann als User via Samba einen Zugriff auf eine Share machst. Dann muss kurzzeitig ein smb Prozess erscheinen der unter deinem User läuft.
Wenn dem nicht so wäre, dann würde der Userprozess als root laufen und dann darf man eben alles. Egal was die Rechte sind, root ist Gott

 

[mr. winterbottom]

sowas kam ....

PID USER STATUS RSS PPID %CPU %MEM COMMAND
1363 root S 1168 1 0.7 0.9 scemd
2356 root R 728 2352 0.5 0.5 top
2213 admin S 7996 1280 0.0 6.3 postgres
2268 root S 6336 1 0.0 4.9 httpd
2063 root S N 5140 1 0.0 4.0 synoindexd
2313 nobody S 4904 2268 0.0 3.8 httpd
2311 nobody S 4904 2268 0.0 3.8 httpd
2312 nobody S 4904 2268 0.0 3.8 httpd
2339 joerg-nb S 3396 2197 0.0 2.6 smbd
2337 root S 3212 2197 0.0 2.5 smbd
2054 admin S 2764 1280 0.0 2.1 postgres
2197 root S 2756 1 0.0 2.1 smbd
2215 root S 2560 1 0.0 2.0 httpd
1280 admin S 2432 1 0.0 1.9 postgres
1283 admin S 2364 1280 0.0 1.8 postgres
2194 root S 1740 1 0.0 1.3 nmbd
2251 root S 1672 2215 0.0 1.3 httpd
2250 root S 1672 2215 0.0 1.3 httpd
2051 root S 1440 1 0.0 1.1 scheduler


mr. winterbottom

 

[jahlives]

Wenn in top während des ganzen Zugriffs kein smb-Prozess unter deinem Benutzernamen kam, dann erklärt das warum du die Dateien löschen konntest. Die Prozesse laufen alle unter root und damit kannst du deine Rechte einstellen wie du willst.
<edit>
Gerade erst gesehen es läuft ja einer unter joerg-nb
</edit>

 

[mr. winterbottom]

das ist alles so unglaublich

... und bei Dir läuft alles wie es soll?
hast Du XP-Clients, VISTA-Clients
Hast Du irgendwas an den Clients eingestellt

kannst mir ja mal Deine smb.conf schicken.
Ich verliere jetzt langsam die Lust

kann das auch an der neuen Samba-Vers. liegen (Bug???)

mir fällt nix mehr ein!!!


mr. winterbottom

 

[jahlives]

Habe es bei mir gerade nochmals getestet:
Datei angelegt und Eigentümer auf User A mit Rechten 0644. Dann als User B versucht die Datei über Samba zu ändern geht ned. Löschen geht ned. Unter anderem Namen abspeichern geht wie es soll, denn sowohl User A als auch User B haben Schreibzugriff auf das Verzeichnis.

 

[jahlives]

Hier mal noch der Auszug aus global meiner smb.conf

workgroup = HOME
server string = Lets SAMBA
encrypt passwords = True
security = user
smb passwd file = /opt/etc/samba/smbpasswd
log file = /opt/var/samba/log.%m
socket options = IPTOS_LOWDELAY TCP_NODELAY
domain master = Yes
local master = Yes
preferred master = Yes
wins support = yes
os level = 65
dns proxy = No
name resolve order = wins lmhosts host bcast
bind interfaces only = True
interfaces = eth0 192.168.1.100 lo
debug level = 0
directory mask = 0755
guest ok = yes
guest account = guest
force directory mode=771
force create mode=660
create mask=771
log level = 0
read raw = yes
write raw = yes
oplocks = yes
max xmit = 65535
dead time = 15
getwd cache = yes

Hast du auch mal

testparm

aufgerufen? Alles okay mit der Konfig?

 

[mr. winterbottom]

noch ne Zwischenfrage.

Deine Namen der Win-Clients sind gleich der Namen der DS-User?
Ich meine damit:

PC1 = UserPC1
PC2 = UserPC2

DS = DSUser

Bei mir sind nämlich die WinUSer = DSUser

Das Du Dich somit immer mit DSUser an der DS anmeldest?
Ich hoffe ich habe mich verständlich ausgedrückt!!!!

mr. winterbottom

 

[jahlives]

Ja bei mir sind die Win User auch als DS User angelegt. Ich möchte mich ja nicht ständig anmelden müssen

 

[mr. winterbottom]

Hammer

Ich wollte echt mal wissen was das bei mir hier auf sich hat.
Das ist fast so unglaublich als ob morgen in der Zeitung steht der Papst wird Vater.

mr. winterbottom

 

[jahlives]

Mach einen letzten Test (sonst ist der Papst echt bald Papa):
Log dich als root mit admin PW auf die Konsole ein und erstelle mal eine Testdatei

touch /volume1/public/test.txt

Dann übergib die Eigentümerschaft an horst

chown horst:users /volume1/public/test.txt

und ändere die Rechte auf 0644

chmod 0644 /volume1/public/test.txt

Jetzt geh als joerg-nb auf die Public Freigabe, öffne die Datei, schreib was rein und versuche zu speichern.
Sag bitte nicht dass du di Datei speichern konntest...

 

[jahlives]

@mr.winterbottom
Der Papst wird Vater
Ich habe das mir bei meinem Samba etwas genauer angeschaut. Ich dachte ja vorher, dass wenn ich die Datei nicht ändern oder lesen kann, dann könne ich sie auch nicht löschen. Aber weit gefehlt: Egal wem die Datei gehörte und wie die Rechte auch waren. Löschen konnte ich sie immer, nur lesen und schreiben nicht (mit 0600 als chmod)!!
Ich werde mal meinen Samba auf die aktuellste ipkg Version bringen und dann nochmals probieren...
<edit>
Auch mit der aktuellsten Samba Version ist es möglich die Datei zu löschen, auch wenn überhaupt keine Zugriffsrechte auf die Datei bestehen

samba - 3.2.7-1 - Samba suite provides file and print services to SMB/CIFS clients.

</edit>

 

[Trolli]

Das Löschen ist von den Ordnerberechtigungen abhängig, nicht von den Dateiberechtigungen.

Trolli

 

[jahlives]

Das Löschen ist von den Ordnerberechtigungen abhängig, nicht von den Dateiberechtigungen.

Trolli

Das habe ich fast befürchtet nachdem ich die Datei ohne Leserechte löschen konnte. Aber immerhin kann man so die Rechte für Ändern und Löschen voneinander trennen

Gruss

tobi