If a user has access to a directory, but root does not, that directory cannot be mounted from Windows. Here's the scenario: We have a directory tree /dat/src that's automounted, and root is mapped to nobody. Under there, we have: jagoldberg $ ls -ld /dat/src dr-xr-xr-x 2 root root 0 Oct 19 2011 /dat/src/ jagoldberg $ ls -ld /dat/src/open drwxr-x--- 3 jagoldberg sa 4096 Apr 25 17:41 /dat/src/open/ jagoldberg $ ls -ld /dat/src/open/hidden drwxr-x--- 2 jagoldberg sa 4096 Apr 25 17:41 /dat/src/open/hidden/ So of course, root cannot see /dat/src/open/hidden: root# ls -ld /dat/src/ dr-xr-xr-x 2 root root 0 Apr 17 16:09 /dat/src/ root# ls -ld /dat/src/open drwxr-x--- 3 jagoldberg sa 4096 Apr 25 17:41 /dat/src/open root# ls -ld /dat/src/open/hidden ls: /dat/src/open/hidden: Permission denied In smb.conf, these directories are defined as [open] and [hidden] respectively: [open] comment = root can read me path = /dat/src/open writable = yes force group = sa force create mode = 0660 create mask = 0660 valid users = @sa [hidden] comment = root can not read me path = /dat/src/open/hidden writable = yes force group = sa force create mode = 0660 create mask = 0660 valid users = @sa From the logs of the attempts to connect to the two shares, it looks like the user context is set back to root too soon. We know this used to work in 3.0.33 (the version running on the majority of our existing samba servers). In source3/smbd/service.c, in the function make_connection_snum(), if we move the line (1007): change_to_root_user(); so that it's at line 1092, right before: return(conn); ...then the mapping and the mounting works correctly. Without access to the directory, root can't canonicalize the name or find out its properties. Here's the difference between the new service.c and the original: > diff service.c service.c.ORIG 1007c1007 < /* change_to_root_user(); jag delta */ --- > change_to_root_user(); 1092d1091 < change_to_root_user(); /* jag delta */ This may not be the best fix - but it does work.
Unfortunately this fix isn't correct. The realpath call is done as root to ensure we end up in the right place across all symlinks. Samba isn't meant to run in an environment where root doesn't have access to the directories being exported. Many other things will subtly break (no chown, no ACLs stored in EA's etc). I'm going to close this as WONTFIX unless you can show me how such things could possibly work under a rootless environment. Jeremy.
Jeremy, thanks for the response and for reviewing the report. I would request that you have a look at the behavior of the system before simply rejecting this bug out of hand. We have a very active production environment that's been working for years exactly as described, using v 3.0.33, which we now need to upgrade due to the unfortunate remote root exploit described in CVE-2012-1182 that led to the release of 3.6.4. In v 3.0.33, the call to "change_to_root_user()" was located just before the "return(conn)" statement. When a user is operating on the files in the share, they do it with their own effective user & group ID, although root is acting on their behalf on the Samba server. Therefore, as noted in the original description, if a user were to connect to the share [OPEN] (/dat/src/open) on the Samba server, they can correctly descend into the subdirectory hidden/, and be able to see and manage its contents. The only disconnect here is when the Samba server canonicalizes the share, the 3.6.4 code calls change_to_root_user()too early in the process. The user is then denied the opportunity to connect to a share that they have access to. I see that this was changed in: http://lists.samba.org/archive/samba-cvs/2010-February/095866.html Jeremy, I see also that this was your change, and done so that "a share can now be defined with a path of /root/only/access (where /root/only/access is a directory path with all components only accessible to root e.g. root owned, permissions 700 on every component). Non-root users will now correctly connect, but get ACCESS_DENIED on all activities (which matches Windows behavior). Previously, non-root users would get NT_STATUS_BAD_NETWORK_NAME on doing a TConX to this share, even though it's a perfectly valid share path (just not accessible to them)." You also mentioned in the change notes that "as this is a change in a core function, I'm proposing to leave this only in master for 3.6.0, not back-port to any existing releases. This should give us enough time to decide if this is the way we want this to behave (as Windows) or if we prefer the previous behavior." So as of 3.6.0, the behavior of Samba has changed based on a decision that you made so that a non-root user will continue not be able to use a share to which he has no access, *but in a more correct manner*. It does, however, now leave a user unable to use a share to which he *does* have access, so I'm asking you to reconsider that the benefit provided by the change that you introduced may be outweighed by users continuing to be able to access resources to which they do have access. Thanks very much for reading this and for your consideration!
You don't understand I'm afraid. Samba has moved on since 3.0.x. We now *rely* on most modern environments on being able to store Windows ACLs in system extended attributes, and there are other places where there is a requirement to access the filesystem being exported as root, or some things will simply break. If you want to continue using 3.0.x, we released a patch for that security issue that should apply to 3.0.33 and you can use that, or you can use your custom patch and hope you don't come across the other issues I mention in your environment, but the days of using not requiring root access on the exported filesystem are gone. Jeremy.