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

Bug #271922 reported by Etienne Goyer on 2008-09-18
8
Affects Status Importance Assigned to Milestone
samba
Fix Released
Medium
linux (Ubuntu)
Low
Unassigned

Bug Description

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.

description: updated
description: updated

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.

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.

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.

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.

Changed in samba:
status: Unknown → Confirmed
Steve Langasek (vorlon) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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.

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) wrote :

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

Changed in samba:
importance: Undecided → Low
status: New → Triaged
Changed in samba:
status: Confirmed → Fix Released
Steve Langasek (vorlon) wrote :

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

affects: samba (Ubuntu) → linux (Ubuntu)
Changed in linux (Ubuntu):
status: Triaged → Fix Released
Changed in samba:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.