Default ACL not applied on files created through CIFS filesystem (mount.cifs)

[Etienne Goyer]

Binary package hint: smbfs

When creating files on a CIFS-mounted filesystem, default ACL are not inherited. However, directory created on same CIFS-mounted filesystem works just fine.

Both server and client are Ubuntu 8.04. On the server, running samba 3.0.28a-1ubuntu4.5, smb.conf is entirely distribution-default, except for the share definition:

[share]
        path = /srv/share
        read only = No
        inherit acls = Yes

Note that, in examples below, ubuntu is uid 1000 on both hardy-server and hardy-desktop.

On the server:

ubuntu@hardy-server:~$ umask
0022
ubuntu@hardy-server:~$ cd /srv/share
ubuntu@hardy-server:/srv/share$ sudo mkdir test-acl
ubuntu@hardy-server:/srv/share$ sudo chown ubuntu:ubuntu test-acl
ubuntu@hardy-server:/srv/share$ setfacl -m d:o:rwx test-acl
ubuntu@hardy-server:/srv/share$ mkdir test-acl/dir-local
ubuntu@hardy-server:/srv/share$ touch test-acl/file-local
ubuntu@hardy-server:/srv/share$ getfacl -R test-acl
# file: test-acl
# owner: ubuntu
# group: ubuntu
user::rwx
group::r-x
other::r-x
default:user::rwx
default:group::r-x
default:other::rwx

# file: test-acl/dir-local
# owner: ubuntu
# group: ubuntu
user::rwx
group::r-x
other::rwx
default:user::rwx
default:group::r-x
default:other::rwx

# file: test-acl/file-local
# owner: ubuntu
# group: ubuntu
user::rw-
group::r--
other::rw-

So far so good. Now, on the client, which have smbfs 3.0.28a-1ubuntu4.6 from hardy-proposed installed:

ubuntu@hardy-desktop:~$ uname -r
2.6.24-20-generic
ubuntu@hardy-desktop:~$ modinfo -F version cifs
1.52
ubuntu@hardy-desktop:~$ umask
0022
ubuntu@hardy-desktop:~$ grep hardy-server /etc/fstab
//hardy-server.montreal.canonical.com/share /home/ubuntu/hardy-server cifs user,username=ubuntu,password=whatever 0 0
ubuntu@hardy-desktop:~$ mkdir /home/ubuntu/hardy-server
ubuntu@hardy-desktop:~$ mount /home/ubuntu/hardy-server
ubuntu@hardy-desktop:~$ cd /home/ubuntu/hardy-server/test-acl
ubuntu@hardy-desktop:~/hardy-server/test-acl$ mkdir dir-cifs
ubuntu@hardy-desktop:~/hardy-server/test-acl$ touch file-cifs

Now, I cannot use getfacl to display the ACL from the client as the cifs module have not been compiled with CONFIG_CIFS_XATTR, but from the server:

ubuntu@hardy-server:/srv/share/test-acl$ getfacl *-cifs
# file: dir-cifs
# owner: ubuntu
# group: ubuntu
user::rwx
group::r-x
other::rwx
default:user::rwx
default:group::r-x
default:other::rwx

# file: file-cifs
# owner: ubuntu
# group: ubuntu
user::rw-
group::r--
other::r--

We can see the directory inherited the default ACL, but the file created on the client over the CIFS-mounted file system do not appear to have got the w permission propagated from the parent directory as expected. Even more puzzling, it appear to work as expected when using smbclient:

ubuntu@hardy-desktop:~$ touch file-smbclient
ubuntu@hardy-desktop:~$ smbclient //hardy-server/share
Password:
Domain=[HARDY-SERVER] OS=[Unix] Server=[Samba 3.0.28a]t
smb: \> cd test-acl
smb: \test-acl\> mkdir dir-smbclient
smb: \test-acl\> put file-smbclient
putting file file-smbclient as \test-acl\file-smbclient (0.0 kb/s) (average 0.0 kb/s)
smb: \test-acl\> quit

Witness on the server:

ubuntu@hardy-server:~$ getfacl /srv/share/test-acl/*-smbclient
getfacl: Removing leading '/' from absolute path names
# file: srv/share/test-acl/dir-smbclient
# owner: ubuntu
# group: ubuntu
user::rwx
group::r-x
other::rwx
default:user::rwx
default:group::r-x
default:other::rwx

# file: srv/share/test-acl/file-smbclient
# owner: ubuntu
# group: ubuntu
user::rwx
group::r-x
other::rwx

I am puzzled. Could it relate to the umask? acl(5) seems to imply it could. But then, the umask is the same on both hardy-desktop and hardy-server (0022) and yet, the actual behavior differ depending on if the file is created locally or through a CIFS-mounted file system (it should not). Maybe I am just confused about what the correct behavior should be in the first place.

[Etienne Goyer (etienne-goyer-outlands)]

The problem could be on the server side. I just tested with Ubuntu 7.10, with the old smbmount and smb kernel module, and the behavior is the same as when using mount.cifs and the cifs kernel module: directory inherit ACL fine, but not files.

[Etienne Goyer (etienne-goyer-outlands)]

Just tested on Intrepid (both client and server), and I get the same behavior: directory created through the CIFS mounted file system inherit the default ACL correctly but files do not, while it work as expected when creating either directory or file using smbclient.

[Etienne Goyer (etienne-goyer-outlands)]

Just tried using the latest upstream source (3.3.0pre2) on the server side with Intrepid, and it fail too. I will report to Samba Bugzilla, and see what they have to say.

[Etienne Goyer (etienne-goyer-outlands)]

However, on Intrepid when using the upstream 3.3.0pre2 from source, file do not inherit default ACL for "other" even when the file is created using smbclient.

I should also note that using an ACL for a named group instead of "other" (ie, setfacl -m d:g:users:rwx) work as expected in all test cases, on both hardy and intrepid.

[Steve Langasek (vorlon)]

There's definitely a client difference here. When smbclient connects, it makes a single OpenAndX request; the kernel cifs client instead calls NTCreateAndX, followed by two SET_PATH_INFO Trans2 requests. The SET_PATH_INFO is probably what's clobbering the ACL.

Partial network trace showing the cifs client requests attached.

[Steve Langasek (vorlon)]

Disabling Unix CIFS extensions with 'echo 0 > /proc/fs/cifs/LinuxExtensionsEnabled', the kernel cifs client now works for me (tested with the current jaunty kernel). Attached is a network trace showing the same operation ('touch file-cifs') with POSIX extensions disabled; the SET_FILE_INFO level is different ('File Basic Info' vs. 'File Unix Basic'),

I don't see anything special in the /content/ of the file info request when POSIX extensions are enabled, so I think this should be considered a server bug.

As an aside, if you're only using user mounts on the client, I would generally recommend POSIX extensions on the client independent of this particular bug, especially given a kernel (such as the one in hardy) that doesn't have CIFS_XATTRS turned on.

Pros of using POSIX extensions for user-only mounts:
- ability to create/use pipes and sockets
- ability to use POSIX locking reliably
- ?

Cons of using POSIX extensions for user-only mounts:
- if you ever authenticate to the server as a user whose remote uid is different from your local uid, the mount will be completely inaccessible to your user because of the pass-through ACL semantics

The current default behavior of mount.cifs is unfortunately really only suitable for system-level mounts where the client and server have the same uid/gid mappings.

[Steve Langasek (vorlon)]

Correction; the perms are being set on request of the client:

[2009/01/24 13:50:41, 5] smbd/filename.c:unix_convert(290)
  conversion finished test-acl/file-cifs -> test-acl/file-cifs
[2009/01/24 13:50:41, 3] smbd/trans2.c:call_trans2setfilepathinfo(6702)
  call_trans2setfilepathinfo(6) test-acl/file-cifs (fnum -1) info_level=512 totdata=100
[2009/01/24 13:50:41, 10] smbd/trans2.c:smb_set_file_unix_basic(5955)
  smb_set_file_unix_basic: SMB_SET_FILE_UNIX_BASIC: name = test-acl/file-cifs size = 0, uid = 4294967295, gid = 4294967295, raw perms = 0100644
[2009/01/24 13:50:41, 10] smbd/trans2.c:smb_set_file_unix_basic(6001)
  smb_set_file_unix_basic: SMB_SET_FILE_UNIX_BASIC setting mode 0644 for file test-acl/file-cifs

So not a server-side bug at all; the server is correctly applying the default ACL, and then also doing as the client has requested, overriding the mode with the new settings.

[Steve Langasek (vorlon)]

And the mode being requested by the client is mediated by the umask.

A full fix for this will require the client to set the mode atomically at file creation time, at a point where the samba server can apply the mode in the open call instead of as a separate chmod() call. The NTCreateAndXRequest RPC call doesn't allow for this, so an RPC call specific to POSIX extensions would be needed here; perhaps the SMB_POSIX_PATH_OPEN Trans2 call allows for this already, but isn't being used by the kernel cifs client?

[Michael Adam (obnox)]

I was looking for a reason why Ubuntu kernels dont have CIFS_POSIX_XATTR set?
So the nifty posix acl extensions can never be used with stock kernel.
Should we open a new enhancement bug report for this or was I just not clever enough searching...

Michael

[Steve Langasek (vorlon)]

Hi Michael,

In the case of Ubuntu 8.10, I think this is principally an oversight. Note, however, that I've also tested this behavior with the jaunty kernel which does have CIFS_POSIX_XATTR set, and it makes no difference to this bug because of the atomicity issue I've outlined.

[Etienne Goyer (etienne-goyer-outlands)]

I can confirm the default ACL for other are being applied correctly on file creation through a CIFS mount with the POSIX extensions disabled, on hardy.

The ability to create pipe and socket is not important in my case, and I think I can do without POSIX file locking. As such, disabling the POSIX extensions is ok with me.

I have not tried on Jaunty or on the latest Samba upstream.

[Pedro Villavicencio (pedro)]

Marking this as triaged since it was sent upstream at https://bugzilla.samba.org/show_bug.cgi?id=5807 ; thanks all.

[Steve Langasek (vorlon)]

Upstream reports this is resolved in the kernel client in Linux 2.6.29 and above; marking fixed here.