Folder group permissions weirdness

DaRkBoDoM · 08-19-2016, 11:17 PM

Hi there!

I have a samba linux server and a samba linux client.
The client mounts a "Recordings" share from the server in "/mnt/recordings".

Here is the mount definition from /etc/fstab:

Code:

//server/Recordings /mnt/recordings cifs rw,nouser,auto,credentials=/etc/samba/credentials,iocharset=utf8,soft,_netdev,comment=systemd.automount 0 0

and here is the related "mount" command output:

Code:

//server/Recordings on /mnt/recordings type cifs (rw,relatime,vers=1.0,cache=strict,username=bodom,domain=WORKGROUP,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.1.1,unix,posixpaths,serverino,mapposix,acl,rsize=1048576,wsize=65536,actimeo=1,_netdev)

Now the problem is: I can't list the folder as "bodom" user. If I try to, I get a "permission denied" error.

Here are the permissions from "getfacl recordings":

Code:

# file: recordings
# owner: lightdm
# group: family
# flags: -s-
user::r-x
group::r-x
other::---

My user "bodom" is member of the "family" group (or at least "getent group" says so).

If login as root on the client, I can access the mounted folder.
If I change the permissions to "o+rx", I can access the mounted folder.
If I change the owner to "bodom", I can access the mounted folder.
If I use the "noperm" mount option, I can access the mounted folder.

So, in the end it looks like my system does not recognize "bodom" as being a member of "family".

Groups and users are inherited from the server via NIS.
I have this at the bottom of my /etc/passwd:

Code:

+bodom::::::
+::::::/bin/false

And this at the bottom of my /etc/group:

Code:

+:*::

Could you help me hunt down this issue?

malekmustaq · 08-21-2016, 10:23 AM

Have you tried create a local user bodom in the server?
Or change group ownership of client mount point to family, not gid=0.

DaRkBoDoM · 08-23-2016, 12:48 AM

Quote:

Originally Posted by malekmustaq

Have you tried create a local user bodom in the server?

Yes, the server has a local user "bodom"

Quote:

Or change group ownership of client mount point to family, not gid=0.

I've just tried, but I am having same behavior

xenmaster · 01-13-2017, 06:04 AM

It is a bug in the cifs.ko module, I think.

I do not understand why, but it checks the group permissions and then gets a negative.

I have written a patch against the cifs.ko kernel source for 4.4.0.x that introduces a "nogperm" option.

The only thing the option does is check if you are a member of the group, and then skip all other tests (which is only one, but still).

So if you are a member of the group you automatically get all permissions.

I... guess I wanted to say that I either didn't dig deep enough to find what was causing it, or this was the easier solution

. But I didn't upload it yet.

The way I remember it the checking of the masks *should* function so that means the module gets the wrong information. However debugging a kernel module... I guess it requires writing to the kernel ring buffer (dmesg) and I haven't done that yet (this time). I just wanted a quick fix so I created a new option. The default of this option is "gperm" so by setting it to "nogperm" it just grants you automatic access.

If you are interested, I can upload it. It has an installation script that should work provided you are using 16.04 Ubuntu and using the latest default kernel. On the other hand it might still work in 16.10, but I haven't tested it.

The installation script will check whether you have the "linux-source" package installed, if not, it will install it. Then it unpacks the relevant part of the source archive in /usr/local/src, uses the supplied tool chain (in /lib/modules/$(uname -r or the latest source?)/build to build the module and leaves it sitting in /usr/local/lib/cifs.ko.

Then running it again with --install will just install it on top of the regular module, saving the existing one as a .bak file.

After a reboot the nogperm option works.

I forgot to say that the script also applies my patch, so it downloads the sources, unpacks the cifs module, applies the patch against the cifs module, and leaves it sitting in /usr/local/lib/cifs.ko. Then --install will copy it on top of the regular cifs.ko.

I just haven't had time or providence to actually create a package (using DKMS) out of it.

So after each kernel update you would have to reapply it. DKMS was the next step, but well, life got busy.

Summary: I have a patch + installation script available but I just need to upload it somewhere. Regards.

xenmaster · 01-13-2017, 06:20 AM

Also, to add, this means the cifs.ko module actually does know about the proper group, and it knows about your groups.

That means the test to check whether you are a member of any of those groups, or rather, that the file in question has a group that you belong to, actually succeeds. The error is not in that.

It is the remaining part that fails. What happens is that the three parts of the mask are checked in turn to see if any yield a positive. Or something like it. This code is not part of cifs.ko, so there cannot really be a bug in it. This must mean that the mask supplied to/by the cifs.ko module must actually be faulty. The perms value for "group" must be faulty. The actual checking is done by a main filesystem component of the linux kernel.

So I would venture that there is a problem with the mask as it is derived or communicated to or by or inside of the cifs.ko module, because the weird part is that the stat() system call actually does see the correct permissions, right. So something is going wrong and I didn't debug it because copying the framework for another option was easier. In addition to that, the patch is only like 3 lines.

Two of which are parentheses ;-). So it is really a one-line patch + the infrastructure for adding another option.

Which was copy and paste, basically

.

Regardless, you did find a bug I believe. I didn't write any bug report but was busy doing some writeup on my option and why it would be useful, but I think it got a tad long

.