Problem with samba shares and SELinux - my experience

English Applications
1

I recently upgraded to Leap 16.0 and still have a bit to learn. In this case it is how samba shares work when I am using Dolphin to move the files from my ~/Downloads directory to the /srv/samba shared hard drive.

My experience has been when moving large files eg .mp4 files >5.0GiB for playing in media player. These files on occasions fail to play and I have found that the issue is due to the SELinux policy configuration. The problem is that SELinux labels are not being applied to new files when moved so the label from the source directory is preserved instead of inheriting the share label.

user_home_t        ā† blocked by Samba
samba_share_t      ā† allowed

So the moved files can be listed but not opened for streaming because they are still labelled

user_home_t

The quick fix I have used is:-

sudo restorecon -RFv /srv/samba/private_data

and to more permanent fix has been to create a relabel script and enable this as a service.
I am posting just in case others have had this problem. My point is that I am still learning about SELinux which I gladly embrace but surely other OSā€™s which have used SELinux for a long time must have developed a better solution for systems using samba. What does this forum think?

2

@Budgie2 Iā€™d suggest a read hereā€¦ SELinux-error after update and create a bug reportā€¦

3

As far as I know when a file is copied to another directory, the file will be created in the destination directory in accordance to the default se-labeling rules of the destination directory.

However on my system this does not work with dolphin.

But when I use the command line with cp -Z it works.

4

That is how it is supposed to work.

Copies create new files, new files get new context (by default).
Moving does not create a new file, context remains.

Not a problem, working as intended.

5

Interesting. Of course I use Dolphin for convenience but cli is fine now I know.
Will need to think through difference between copy and move when using Dolphin. Does this make Dolphin the culprit I wonder.

6

On my system

  1. using dolphin to copy a file to destination will always result in the file still having its original selinux-contex in the destination.
  2. using dolphin to move a file to destination will always result in the file keeping its original selinux-contex in the destination.
  3. using cp on the command line to copy a file to destination will always result in the file receiving the selinux-contex of the destination.
  4. using mv on the command lineto move a file to destination will always result in the file keeping its original selinux-contex in the destination.

As far as I know 2.-4. are the expected behaviors.

Iā€™m not sure if 1. is a bug or if dolphin is supposed to behave that way (or if there is some special dolphin-command which will deliver the same result as 3.).

7

With the way KDE is structured, the bug is in kio not Dolphin. Iā€™m not exactly a C++ developer so tracking where everything is going is a serious pain so I canā€™t tell if itā€™s just using the same logic to move without unlinking the source file or if when it copies the permissions to the new file it is including the SELinux context as well.

Either way itā€™s doing the wrong thing and thereā€™s already a bug in KDEā€™s bug tracker https://bugs.kde.org/show_bug.cgi?id=498443 I donā€™t know if you can vote on an issue there or if you just have to add that youā€™re seeing it as well but you should probably do one of those things. It was reported over a year ago but probably isnā€™t seen as a huge issue.

There is also some workaround in the comments of that bug that might be useful.

1 Like
8

Thank you for pointing out the bug report. I added a comment.