F14: Cannot enter home directory. Using /

[Uqbar]

I've installed F14 to replace another distribution on my PC. I chose to use KDE.
I used to have a separate partition for my user home to be mounted as /home.
During the installation I instructed the installer to do so (without formatting of course).
At the first boot I created a use with the very same name as I used to have.
I got the warning about the home being already there and I said "yes, please convert that ownership and selinux stuff so I can use that very directory as my home".
At the graphical login I get a dialog saying I cannot enter my home and that it will use / instead.
Of course the login process fails.
If I switch to the character console (CTRL-ALT-F2) and do a login I actually get the very same error.
But, if I hit "cd" (change directory to $HOME), then I get in the proper directory.
How can I fix this issue? Thanks.

Update 1. I guessed it was a SELinux problem. And I manually disabled it into /etc/selinux/config.
Now I'd like to fix this issue, because I'd like to have SELinux working.

[smr54]

Not sure of the exact issue--however, if you use permissive, rather than enabled, in /etc/sysconfig/selinux, it might (and of course, might not) give the warning, then, when you click on the warning, tell you exactly how to fix it.

This has gotten better with each release, that is, its explanation of what's going on and how to fix it, so I think it's worth a shot.

[Uqbar]

That's scaring as well.
The installation understood what was going on and asked me whether I was willing to fix permissions and SELinux stuff.
I said "yes, please" and he screwed up the SELinux stuff. Better having it disabled, IMHO.
Does anyone know what's the actual thing done during that action?

[jpollard]

Don't disable it - identify the real problem. There should be a log entry.

My initial guess is that the security label on /home is not valid - or whatever
directory the home directory is in. That directory should have the label
"system_u:object_r:home_root_t:s0".

I would guess that the SELinux fix, only changed the label on the home
directory and did not include the full path entries (if home dir is /home/self,
then "self" got the label "unconfined_u:object_r:user_home_dir_t:s0" , but
/home did not get "system_u:object_r:home_root_t:s0".

With the limited information so far, this is just a guess.

[Uqbar]

Originally Posted by jpollard

Don't disable it - identify the real problem. There should be a log entry.

My initial guess is that the security label on /home is not valid - or whatever
directory the home directory is in. That directory should have the label
"system_u:object_r:home_root_t:s0".

I would guess that the SELinux fix, only changed the label on the home
directory and did not include the full path entries (if home dir is /home/self,
then "self" got the label "unconfined_u:object_r:user_home_dir_t:s0" , but
/home did not get "system_u:object_r:home_root_t:s0".

With the limited information so far, this is just a guess.

What you say is very close to Aramaic to me.
I don't know anything about SELinux (apart of what it roughly is).
Where is this "label" thing?
How can I read it? How can I modify it? Is there any "consistency check" (a-la fsck)?
And, most important things, why it's wrong?
Why should I bother, in the 21st century?

[jpollard]

The SELinux label is part of the inode of every file.

It is viewable with the "ls" option "-Z".

there are several ways to modify it. One is using the "chcon" utility
which works on a file by file basis. Another, though lengthy, is
to create the file /.autorelabel (you have to be root and use
the command "touch /.autorelabel", then reboot). This is a lengthy
pass as it will check every file for validity, and correct any errors.

Why it's wrong - Unfortunately, it is rather easy - When you create
a file/directory it receives the default label specified by the user (in
this case root). This default is not the label that should be used for
a directory that will contain home directories. Using a different label
makes it harder for malicious software to attack the system. Being
a different label prevents programs/users from gaining access to things that
shouldn't be granted by accident.

And the last question is actually backwards. Instead of "Why should
I bother, in the 21st century?" it should be "Why shouldn't I be safer
in the 21st century?"

[Uqbar]

Originally Posted by jpollard

The SELinux label is part of the inode of every file.

It is viewable with the "ls" option "-Z".

there are several ways to modify it. One is using the "chcon" utility
which works on a file by file basis. Another, though lengthy, is
to create the file /.autorelabel (you have to be root and use
the command "touch /.autorelabel", then reboot). This is a lengthy
pass as it will check every file for validity, and correct any errors.

Thanks for the quick overview.

Originally Posted by jpollard

Why it's wrong - Unfortunately, it is rather easy - When you create
a file/directory it receives the default label specified by the user (in
this case root). This default is not the label that should be used for
a directory that will contain home directories. Using a different label
makes it harder for malicious software to attack the system. Being
a different label prevents programs/users from gaining access to things that
shouldn't be granted by accident.

Unfortunately the installer seemed to understand what I was going to do and said it was going
to fix permissions and SELinux labels on my behalf.
What actually happened is that the "fixing" procedure is somehow buggy leaving me with an unusable system.
And there seemed to be no way to fix it by hand unless you really know how SELinux works ... or unless you disable SELinux completely.

Originally Posted by jpollard

And the last question is actually backwards. Instead of "Why should
I bother, in the 21st century?" it should be "Why shouldn't I be safer
in the 21st century?"

My question was meant to have a different meaning.
I have not chosen to have SELinux or not. It's integral part of Fedora (I do think it's a good idea).
But the installation procedure is buggy and clearly not throughly tested.
So, why on 21st century Earth should I need to study a brand new (to me) technology just to be able to log into my system?
Shouldn't it be better to have a question like "Do you want to enable SELinux?" or a dialog saying "In order to enable/disable/fix SELinux please run the following program ..."
If I was among the engineers there, I would have run a SELinux consistency check script on the whole system, or at least on the /home subtree. Just in case ...
Of course a safer system is better, and I need to thank Fedora engineers to have added some more security by design.

---------- Post added at 09:30 AM GMT ---------- Previous post was at 09:27 AM GMT ----------

Originally Posted by dto

I just had this happen after a new install last night. I'm pretty sure all I did to correct it was to log in as root and do a chown -R user /home/user, where user is the actual name of the user account.

That was my first action which actually did nothing as ownership had been already fixed by the installation procedure.
It seems that (at least in my case) only the SELinux labels were left behind.
I was using x86_64 DVD medium, by the way. Maybe x86 installation shows different behaviors.
Which would then be a bug on its own.

[dto]

I just had this happen after a new install last night. I'm pretty sure all I did to correct it was to log in as root and do a chown -R user /home/user, where user is the actual name of the user account.

[jpollard]

Hmmm. It could be a bit of a bug..

It is possible that the developers didn't think of this case. I did have
something similar when I migrated from fedora 11 to fedora 13.

The new (upgraded) system had everything working just fine... except
for one SELinux label buried in the user structure.

This bug (sort of) turned out to be due to a rather large update to the
SELinux security definitions (more finely grained isolation), and the new
definitions assigned a different binary number to one definition... When
I did a manual relabel (it was suggested in the log), the problem disappeared.

Until I rebooted Fedora 11.

This type of change doesn't occur very often. I'm pretty sure that a
"touch /.autorelabel" would have fixed it.. But, depending on the
environment, that is not something you want to do.

Doing a relabel on a large filesystem (10,000 files and up) can take
hours and hours for a single processor scanning a 2 TB filesystem.
I used to work with filesystems with up to 50 million files... It could
take days to relabel that way.

I do know a faster way - but implementing it isn't graceful, as the
technique uses a multi-threaded scanner (each thread scans a directory
for files to be labelled, and for each directory found, either adds another
thread, or adds the directory to a work queue) - and that can overload
small systems (under 12GB) rather quickly, and even slow things
down more in small systems. It is rather quick when the resources are
available - scanning 49 million files only took 45 minutes for a backup
scan.

Like fsck, the ./autorelabel is not something to do every time, only when
known fixable errors occur. Many SELinux errors are not, or should not,
be fixed this way as it really is up to the administrator to decide about
these fixes. Just as the administrator needs to understand a bit about
filesystems to use fsck, SELinux requires the administrator to understand
a bit about SELinux labels.

I do agree that some more/different documentation on installation would
help. There is a good bit of SELinux documentation at

http://docs.fedoraproject.org/en-US/...nhanced_Linux/

Though it may not be focused on what to do for "expected" errors
like this one..

[Mountainmonkey]

I get the same error when i try to log in to KDE with my ordinary user.

I manage to log in as root.

If i log in with my user in a shell, everything seems to be ok: I get to my home-directory, and the files belongs to my user, and i manage to touch a file, so i have write access. I did not let the system do any auto-configuration and changes of ownership of files, during installation of Fedora 16.
During installation, i got a warning that it might be trouble to use user IDs less than 1000. I am using 501. I can't understand why the number of the user UID should matter, and i am not sure if i trust this system, if it depends on the UID this way. It is a long time since i used RH/Fedora-family, and i switched from it in the 1990-s, so i don't know it so well. Tonight i tried to return, but may be i should wait for the next release of Fedora?

[jpollard]

The UID reference is that from F16 on, the base user UID counting will start from 1000, and not from 500.

Other than a warning, there shouldn't be any real problems.