Cfrtjryk

I am trying to set samba context on directory with following command
and I am not sure what this error is about but I can not set the context on directory.

semanage fcontext -a -t samba_share_t "/common(/.*)?"

error Thrown as follows:

Full path required for exclude: net:[4026532292].

The error you see is not caused by applying samba_share_t context on /common directory. You can still try restorecon -R /common, and check selinux context is indeed changed. I believe the error originates from previous configurations.

It's been over a year since this was asked, but I didn't find an answer online. Let's fix that for the next person. :)

Those errors occur because something has created network namespaces on your machine. If you look at the output of mount you'll see a proc filesystem type mounted somewhere (probably under /run or /var/run) with that number. However, if you look at /proc/mounts like restorecon (and semanage) does, you'll see the same filesystem with "net:[xxx]" as the mount point. Unfortunately, restorecon / semanage have no idea how to deal with that; they just see a path which doesn't start with a / and emits an error.

Why does it do that? If you check out the restorecon source, you'll see that restorecon automatically adds exclude entries for mountpoints which don't have the seclabel mount option set. Same presumably goes for semanage. The seclabel option should be managed by SELinux, I think. What it does is indicates that the filesystem uses xattrs to store the SELinux attributes. That's why those filesystems are being excluded: it doesn't make sense to try to set the context on files when the filesystem doesn't support SELinux contexts.

Great. How do you fix it? The selinux_restorecon() syscall includes a flag - SELINUX_RESTORECON_IGNORE_MOUNTS - which instructs it to not bother with that check, but there doesn't seem to be a way to tell the restorecon or semanage programs to do the same. So, one option is to write your own restorecon program which makes that syscall with the flag to ignore mount labels. That's a pain. :) An easier option I like is to just use a mount context to hide those mount points you're probably not interested in traversing anyway. Contexts cause the problem, so why not fix it with contexts too?

sudo unshare -m sh

umount $( mount | awk '$3~/netns/{print $3}' )

restorecon -rv /some/file

exit

Use unshare -m to create a new mount namespace and run sh (pick your favorite shell here) in that namespace. Then unmount the offending filesystems. In my case with Docker doing this, the filesystems all include netns (and I have no filesystems with that string), so I just pull the matching mountpoints out and pass those to umount. Someone else might need to find and unmount differently, but the idea is the same. Because unshare -m defaults to a private mount namespace, the unmounting doesn't impact anything else on the system - it basically hides the mounts from this process. At that point, I have a shell where those filesystems are not visible. So, when restorecon inspects /proc/self/mounts (it technically opens /proc/mounts, but for backwards compatibility that's a link to /proc/self/mounts on systems which support mount namespaces) in the namespace it inherits from the shell, it's able to run with no problems.

If you find yourself doing this often, it would probably make sense to put the umount and restorecon into a shell script and just run that with restorecon instead of starting a shell.