I was setting up a Samba server and I ran into some problems with SELinux related to the context of the home directories.

I made a user account, say "UserAccount", with a default home directory "home/UserAccount". Afterwards I realized that I needed to move the home directory of this particular user to another location, say "/home2/UserAccount". So I created the new directory, changed the permissions, and used Gnome's system-config-user to change the user's home directory.

I then set-up the Samba server, activated samba_run_unconfined and samba_enable_home_dirs in SELinux, and made an account for UserAccount.

When testing the Samba account for UserAccount SELinux denied read access. I checked the context and the new home directory did not appeared to have been updated. I had to manually run:

restorecon -R -v /home2/UserAccount

to set the context on the new home directory.

I'm not very familiar with SELinux, so my question is this: is this normal security policy or is a bug in the system-config-user tool? If it's normal policy can someone explain why? I'm always ready to learn ...

Distro: Fedora 12 (kernel: 2.6.31.5-127.fc12.i686)
System: Dual Intel Xeon @ 3.2 GHz, 1 GB RAM

Whats the output of...

You MIGHT have to do a...

Thx for the reply custangro.

I may not have been clear in my previous post, but I did already solve the access problem. The thing that I wanted to know is why I had to manually restore/update the context of the new home directory (using restorecon).

I'm not an expert so it took me a while to find out what was wrong. It seems that the system-config-user tool already sets the correct context. It simply does not update the new context automatically.

So my question is: why? Would this be a security risk? If so, why not present the user with a warning message? Or is it simply a bug in the tool that I should report?

And just to be clear:

After I performed the restorecon on the new home directory everything was OK. The folder now has the user_home context:

That was not necessary because system-config-user already added the user_home context. And since I have home directory sharing switched on in Samba and I have given it the correct permission in selinux, it works fine, after restoring/updating the context.

If an account is created using the standard system administration utilities like {group,user}-add then the right context will be set. system-config-users is used for adding and removing users and groups to the system (as in user-add, group-add, chage and not chcon unless I'm mistaken) so changing aspects outside the scope of that kind of user management, or manually creating directories(?) (and moving files?) as root account user overrides any previously set contexts. Given the scope of those tools I'd agree a manual 'chcon' would be in order and having to perform it looks procedurally right to me.

I understand what you're saying unSpawn. But it seems to me that if the system-config-users tool allows me to make changes to a user account (not just add/remove), it should not do only half of the job and not set the correct context. But perhaps the same happens when using usermod -d [new dir] (without the -m option)? I'll check that.

Any way, I think I'll stick with the command line tools to better understand the steps involved and prevent this type of things from happening again.

Thanks for taking the time to reply.