[SOLVED] SELinux preventing me from accessing external disk

[vuarnet]

Hello, I'm new to SELinux, but I'm picking it up quite quickly thanks to the new tools in CentOS 7 for troubleshooting. Here's some background:

I'm running a fully-patched version of CentOS 7 64-bit using the Nautilus file manager (gnome as desktop)
I have no issues accessing the external hard drive until I set my user to "staff_u" context
My current user is mapped to the selinux user "staff_u" and I allow my user sudo, but I also have a backup root user until I get all this figured out (I've locked myself out of my system several times without a root user and no sudo permissions a few times now...)

When I set my user to "staff_u", I get the following when I try to access my hard drive:

"The location could not be displayed.
You do not have the permissions necessary to view the contents of "[Hard drive name]".
[OK]"

No AVC denials pop up, unless I try to change permissions as non-root.

When I look at permissions, it says "me" as the owner, and the access is "create and delete files", but the security content is:

system_u:object_r:file_t:s0

Because there is no AVC denial here, I'm having a difficult time getting it to work.

When I set SELinux to permissive, everything works fine -- I can r/w to the drive just fine. When I turn it back to "enforcing", I get the same denial where I can't read or write to it.

Any help would be greatly appreciated!

Thanks!

[gerald_clark]

Hard drives don't have names.
Logical devices ( LVM or partitions) hold filesystems that are mounted to directories.
The permissions on those mounted directories determine which users can read, write, or search those directories.

Now, if you can be more specific, what is the problem?

[vuarnet]

Hard drives don't have names.
Logical devices ( LVM or partitions) hold filesystems that are mounted to directories.
The permissions on those mounted directories determine which users can read, write, or search those directories.

Now, if you can be more specific, what is the problem?

Thanks for the reply and for taking the time to help.

Ok so not 'hard drive name' ... Physical volume, I guess. It's encrypted with luks (via cryptsetup) and the first and only partition is at sdc1 and is ext4.

It decrypts fine, but when I try to read the files or do anything to the drive, I get a permission denied issue as stated above. I'm thinking it may be a label issue but I'm not sure if it's instead a boolean I need to set to mount external devices (not in fstab).

Any guidance is very much appreciated. If you tell me what details are helpful, I'll gladly do what I can to provide then.

I'm assuming it's SELinux related since I can mount the disk just fine when I'm in enforcing mode with unconfined user AND when I'm using staff_u user and in permissive mode, but NOT when I'm in enforcing mode and using staff_u user mapping.

All the best.

[TrevorH]

system_u:object_r:file_t:s0

This is the "I don't know what context to give this so I'll use this" context that is used when something is not labelled correctly. The correct way to fix this is to first use semanage to add a new rule to assign a "good" context to your files and tell it to assign that to the directory where you mount your luks encrypted volume. Once you've used semanage fcontext -a -t some_selinux_type_t '/path/to(/.*)?' to add the rule, then you run restorecon -r on /path/to and it'll fix up the contexts and you should be able to access the files.

[vuarnet]

system_u:object_r:file_t:s0

This is the "I don't know what context to give this so I'll use this" context that is used when something is not labelled correctly. The correct way to fix this is to first use semanage to add a new rule to assign a "good" context to your files and tell it to assign that to the directory where you mount your luks encrypted volume. Once you've used semanage fcontext -a -t some_selinux_type_t '/path/to(/.*)?' to add the rule, then you run restorecon -r on /path/to and it'll fix up the contexts and you should be able to access the files.

Thanks TrevorH! This is precisely what the issuing thee was. I first used chcon to fix the issue after reading through more redhat documentation, and then after reading your solution, I found that yours is best long-term because (as I didn't know at the time) chcon does not survive a filesystem relabel whereas fcontext does.

Unfortunately, fcontext cannot handle spaces in volume names... so I had to actually copy all my data to another hard disk, but it was well worth the trouble now that it's working as intended.

Thanks for the help, I'll edit the subject to reflect the "issue" as resolved.