selinux - change directory failed: permission denied

[774 states]

When I log in via the console with SELinux enabled, I get the error "-- user: /home/user: change directory failed: Permission denied
Logging in with /home="/"."

Then it drops my shell to / instead of my home directory, but I can still read and write /home/user so once in the shell I have access to /home/user and file permissions are ok.

If I disable SElinux, then I go straight to my home directory upon log in with no error. Also, if I do not mount the /home partition but use a directory in /, then the error does not occur. FWIW the /home was added after installation was completed.

Which logs should I be looking in for the error messages and which settings in SE linux must I change?

[Skull One]

I guess your home directory is not correctly labeled.
You can check using 'ls -lZ /home'. The users directory labels must be:

unconfined_u:object_r:user_home_dir_t

Just run as root

restorecon -R /home

to let SELinux restore the filecontexts of /home.

[774 states]

Thanks that does seem to be the problem. The /home that works has the context "unconfined_u:object_r:home_root_t:s0", the /home that does not work is "system_u:object_r:dosfs_t:s0"

However, "restorecon" doesn't seem to change anything even when run as root. Are there some options that are missing? I am a complete novice with SELinux.

[Skull One]

I was not clear, sorry:
/home must have the context home_root_t, and was probably good.
/home/* must have the context user_home_dir_t, and the problem is probably here.
As you can see, the labels are quite explicits. The restorecon command must set the contexts like this.

By the way, you are here talking about TWO /home ??? That point is not clear for me.

[lklaus]

Also, if you had selinux turned off for some time (it's better to set it to permissive, if you suspect selinux to block something) best is to "touch /.autorelabel" and reboot.

[774 states]

Thanks. Yes, there were two homes involved. One is just a directory on /, that one is a thow-away. The other is a separate partition which uses /home as the mount point. It is that one which I need but is giving the error. It's been many years since using Fedora/RH, so I have a lot to catch up on.

I've just found the utility SE Linux Troubleshooter. That has found a problem with /usr/bin/login

[Skull One]

Thanks. Yes, there were two homes involved. One is just a directory on /, that one is a thow-away. The other is a separate partition which uses /home as the mount point. It is that one which I need but is giving the error. It's been many years since using Fedora/RH, so I have a lot to catch up on.

I've just found the utility SE Linux Troubleshooter. That has found a problem with /usr/bin/login

Ok.
Let's call the first your secondary home.

Could you report the error message? I guess it is related to the labelling problem.
Could you also report the output of

ls -lZ /home/

And could you also report the label of your secondary home, since it works fine?

[774 states]

The error messag is in #1 above, the output of ls -lZ

drwxr-xr-x. foo foo system_u:object_r:dosfs_t:s0 foo
drwxr-xr-x. bar bar system_u:object_r:dosfs_t:s0 bar

The secondary home has this label:

drwxr-xr-x. foo foo unconfined_u:object_r:home_root_t:s0 foo
drwx------. bar bar unconfined_u:object_r:user_home_dir_t:s0 bar

[Skull One]

The error messag is in #1 above, the output of ls -lZ

I was talking about the troobleshooter message.

drwxr-xr-x. foo foo system_u:object_r:dosfs_t:s0 foo
drwxr-xr-x. bar bar system_u:object_r:dosfs_t:s0 bar

The secondary home has this label:

drwxr-xr-x. foo foo unconfined_u:object_r:home_root_t:s0 foo
drwx------. bar bar unconfined_u:object_r:user_home_dir_t:s0 bar

Damn, what is this? How could we map a label to a directory if you do not report it with its full path?
I guess the first line stand for /home, and the second for /home/<user>: the secondary home is therefore correctly labeled, and not the primary one, since the label is 'dosfs_t'.

Since it is mounted on /home, the restorecon must fix it.
if you cannot/don't want to use this command, you cant set the label manually :

chcon -t home_root_t /home
chcon -t user_home_dir_t /home/<user>

[774 states]

The two chcons give the following errors when run as root:

chcon: failed to change context of `/home' to `system_u:object_r:home_root_t:s0': Operation not supported

chcon: failed to change context of `/home/lars/' to `system_u:object_r:user_home_dir_t:s0': Operation not supported

---------- Post added at 02:00 PM ---------- Previous post was at 01:47 PM ----------

Here are the data from the SE Linux Troubleshooter. Running restorecon doesn't seem to stop the error when logging in from the console:

SELinux is preventing /usr/bin/login from search access on the directory /home.

***** Plugin restorecon (99.5 confidence) suggests *************************

If you want to fix the label.
/home default label should be home_root_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /home

***** Plugin catchall (1.49 confidence) suggests ***************************

If you believe that login should be allowed search access on the home directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep login /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context system_u:system_r:local_login_t:s0-s0:c0.c1023
Target Context system_u:object_r:dosfs_t:s0
Target Objects /home [ dir ]
Source login
Source Path /usr/bin/login
Port <Unknown>
Host localhost.localdomain
Source RPM Packages util-linux-2.21.2-1.fc17.x86_64
Target RPM Packages filesystem-3-2.fc17.x86_64
Policy RPM selinux-policy-3.10.0-132.fc17.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name localhost.localdomain
Platform Linux localhost.localdomain 3.4.3-1.fc17.x86_64 #1
SMP Mon Jun 18 19:53:17 UTC 2012 x86_64 x86_64
Alert Count 2
First Seen Mon 25 Jun 2012 01:53:54 PM EEST
Last Seen Mon 25 Jun 2012 01:53:54 PM EEST
Local ID 8e3c23c7-a37f-4b33-b8e2-ce837109e9ca

Raw Audit Messages
type=AVC msg=audit(1340621634.333:273): avc: denied { search } for pid=27344 comm="login" name="/" dev="sda7" ino=2 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dosfs_t:s0 tclass=dir


type=SYSCALL msg=audit(1340621634.333:273): arch=x86_64 syscall=chdir success=no exit=EACCES a0=fd75c4 a1=0 a2=7fff04000000 a3=8 items=0 ppid=27331 pid=27344 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=tty4 ses=21 comm=login exe=/usr/bin/login subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 key=(null)

Hash: login,local_login_t,dosfs_t,dir,search

audit2allowunable to open /sys/fs/selinux/policy: Permission denied


audit2allow -Runable to open /sys/fs/selinux/policy: Permission denied

[Skull One]

What is the filesystem of the partition?
It must support extended attributes, since SELinux store the labels inside.
I guess it is a FAT filesystem since the label is 'dosfs_t'. In this case, it cannot be handled by SELInux, which explains the error messages from chcon.

[774 states]

It is shared triple boot (Lubuntu, OS X, and Fedora) so it is HFS+. I'd like to move it to EXT but don't know of a way yet to get OS X to read EXT.

[Skull One]

Outch! HFS+...
I don't really know this filesystem, but I have heard that it is not yet completly supported. Maybe the extended attributes lack support? I cannot tell...
From what I understand, all the problem is here.

And I can think of some solutions in that case, but I do not like them.
1). (the best in my opinion): change the mount point of the partition.
2). There is a mount option that allows you to set the SELinux context of the partition, so it could work with some luck.
3). (I really do not like this) Write a policy to enable the access to 'dosfs_t'. The troobleshooter gave you some clues.
4). Disable SELinux. Lubuntu and OSX do not use it after all.

[domg472]

Use a file system that support extended attributes. Alternatively you can mount the file system with a "rootcontext=" specified, but that is not going to be a workable solution foruser home directories.

See "man mount" look for context and rootcontext mount options