Bug 14201 - DFS mount does not pass context option to actual share mounts
Summary: DFS mount does not pass context option to actual share mounts
Status: RESOLVED FIXED
Alias: None
Product: CifsVFS
Classification: Unclassified
Component: kernel fs (show other bugs)
Version: 3.x
Hardware: All All
: P5 normal
Target Milestone: ---
Assignee: Steve French
QA Contact: cifs QA contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-11-18 15:17 UTC by Patrick Böker
Modified: 2022-07-26 13:55 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Böker 2019-11-18 15:17:19 UTC
OS: CentOS 8
Kernel: 4.18.0-80.el8.x86_64
cifs-utils: cifs-utils-6.8-2.el8

I try to mount a DFS share with mount.cifs (notice the `context=...` option to set an SELinux label):

    mount.cifs //some/cifs/share /var/mounts/share -o ro,iocharset=utf8,user=[*],password=[*],dir_mode=0555,file_mode=0444,context="system_u:object_r:container_file_t:s0"

When I do `ls -lZ /var/mounts/share` I get something like:

    drwx--x--x. 2 root root system_u:object_r:container_file_t:s0 0 Nov 14 15:59  Some_folder
    drwx--x--x. 2 root root system_u:object_r:container_file_t:s0 0 Nov 14 15:59  Other_folder
    # ... more folders all having the same label

When I access one of those folders (an actual share) with `ls -lh /var/mounts/share/Other_folder` the SELinux labels change as follows:

    drwx--x--x. 2 root root system_u:object_r:container_file_t:s0 0 Nov 14 15:59  Some_folder
    dr-xr-xr-x. 2 root root system_u:object_r:cifs_t:s0           4.0K Oct 17 12:24  Other_folder

Also when looking at the mount that transparently happened in the background using `mount` the following shows up:

    //some/cifs/share on /var/mounts/share type cifs (ro,relatime,context=system_u:object_r:container_file_t:s0,vers=default,cache=strict,username=[*],domain=,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.1.100,file_mode=0444,dir_mode=0555,soft,nounix,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)
    //some_actual_share/Other_folder on /var/mounts/share/Other_folder type cifs (ro,relatime,vers=default,cache=strict,username=[*],domain=,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.1.5,file_mode=0444,dir_mode=0555,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)

As can be seen the DFS share (the first line) has the `context=` option set, but the automatically mounted real share (the second line) misses that option.

I think this is broken behavior and the `context=` option should be forwarded so the specified SELinux labels are correctly set on DFS shares.


In my concrete case this wrong labeling prevents access to that share from containers. My current workaround is lifting the SELinux restrictions by passing `--security-opt label=disable` to podman / docker.
Comment 1 Paulo Alcantara 2022-07-25 16:49:05 UTC
Hi Patrick,

Does this still occur with mainline kernel?
Comment 2 Patrick Böker 2022-07-26 07:29:21 UTC
Hi Paulo,

have there been patches that could have fixed this? I'm willing to do the testing. I just looked up what mainline kernel means. Is there a simpler way to test mainline than compiling my own? (It's been more than 10 years since I last compiled my own Linux kernel.)
Comment 3 Patrick Böker 2022-07-26 12:34:36 UTC
I have tried this again on a fresh Fedora 36 (Kernel 5.17.5). This test system does not show the described behavior anymore.
Comment 4 Paulo Alcantara 2022-07-26 13:15:01 UTC
Hi Patrick,

It's OK, no problem :-)  Some distros generally have their own packages to easily tests latest kernels in case you don't want to build your own.

There were several DFS related patches since the last version you tested (4.18), so yes, some of them might have fixed your last issue.

Can we close this bug now?

In case you are able to reproduce it again, feel free to reopen it.  Thanks.
Comment 5 Patrick Böker 2022-07-26 13:55:57 UTC
Works on 5.17.5. So I assume it got fixed in the meantime.