Bug 2619 - group write access via ACLs show unexpected behaviour
Summary: group write access via ACLs show unexpected behaviour
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.13
Hardware: x86 Linux
: P3 regression
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
Depends on:
Reported: 2005-04-15 09:40 UTC by Peter Kruse
Modified: 2005-09-07 07:28 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Peter Kruse 2005-04-15 09:40:34 UTC

this could be related to #2606 and #2521 but am not sure if this is a duplicate.
Anyways I was asked to file this as a bug.

Here is what happens:

Create a file with permission bits set to 470, owned by root. 
With setfacl give write permission to a group.  Users in that
group will not be able to modify the file when accessing the share
from a windows client.  This is true for smbclient as well.
Modifying the file under Linux works as expected.

$ ls -l testi2.txt
-r--rwx---+ 1 root QLEAP+domänen-benutzer 14 Apr 15 16:40 testi2.txt
(Note the file belongs to root but has no write permission)
$ getfacl testi2.txt
# file: testi2.txt
# owner: root
# group: QLEAP+dom\303\244nen-benutzer
$ id
uid=10032(QLEAP+testi2) gid=10029(QLEAP+domänen-benutzer)
$ vi testi2.txt
(can edit the file)
$ smbcacls  -U testi2 //hatest1/admin testgruppe20/testi2.txt
creating lame upcase table
creating lame lowcase table
$ smbclient  -U testi2 //hatest1/admin
creating lame upcase table
creating lame lowcase table
Domain=[QLEAP] OS=[Unix] Server=[Samba 3.0.13-Debian]
smb: \> cd testgruppe20
smb: \testgruppe20\> lcd /etc
smb: \testgruppe20\> put passwd
putting file passwd as \testgruppe20\passwd (1122.9 kb/s) (average 1123.0 kb/s)
smb: \testgruppe20\> put passwd testi2.txt
NT_STATUS_ACCESS_DENIED opening remote file \testgruppe20\testi2.txt
smb: \testgruppe20\> q

Please see also:

thanks for your attention,

Comment 1 Jeremy Allison 2005-04-19 00:53:49 UTC
Please send me the debug level 10 log from smbd when doing the smbclient
operation listed below.
Comment 2 Peter Kruse 2005-04-19 10:00:44 UTC
(In reply to comment #1)
> Please send me the debug level 10 log from smbd when doing the smbclient
> operation listed below.

Did you receive the log?  I had a look at them myself and saw this:

[2005/04/19 10:25:32, 8] smbd/dosmode.c:dos_mode_from_sbuf(151)
  dos_mode_from_sbuf returning r
[2005/04/19 10:25:32, 8] smbd/dosmode.c:dos_mode(315)
  dos_mode returning r

which looks like not related to acl at all.  And I think this is what
- when a user changes the dos attribute to readonly it is translated by samba to
remove the write permissions of the unix-user part (u-w)
- the next time the user wants to access the file she receives a permission
denied because because samba translates the u-w permission back to readonly
- in this special case she even cannot remove the readonly flag again because
she's not the owner of the flag (that can be overwritten with "dos filemode = yes")
- notice that ACLs are not involved at all.

Ok, the question is: bug or feature?
Would the solution be to use extended attributes and do this?

store dos attributes = yes
map hidden = no
map system = no
map archive = no

I have not yet tested with extended attributes, but I would
expect it will work, please correct me.
The root of the problem lies in the fact that samba translates dos attributes
to unix permissions (and fate takes its run...)
The question remains: are you or have you been aware of this?
Comment 3 Nerijus Baliūnas 2005-04-21 06:25:33 UTC
IMO by default it should work like in Windows. I.e., if doc or xls file has a
read only attribute on Windows, Word or Excel can still modify such file. After
I copy file to samba share, it gets u-w permission, and Word or Excel can no
longer modify file, until I remove r/o DOS attribute.
Comment 4 Gerald (Jerry) Carter (dead mail address) 2005-09-07 07:28:10 UTC
This all needs to be reevaluated in light of 3.0.20.
If there is still a bug here, please reopen.