[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: F7: SELinux feature or bug?

Daniel J Walsh wrote:
Mikkel L. Ellertson wrote:
Jeroen Lankheet wrote:
Hi all,

I think I've been stupid or framed or both. I wanted to samba share a
USB disk on a F7 system but got an SELinux message saying that the
directory could not be shared, and that there was a command to get it
right (=wrong?).
So I typed in

chcon -t samba_share_t -R /

Yes, that's what was in the SElinux message thingie as suggestion. And
being a total SELinux nitwit I did what the almighty Linux system adviced.
So it took a while before getting "operation not permitted" on /dev/....
Then I cancelled the operation but the damage has apparently already
been made.
I retyped the command with the proper directory to share and now the
share worked.
But when I restarted the system all kinds of services were broken
including /dev/eth0.
The kernel could not find the eth0 device. The X configuration was gone
and all kinds of errors were smashed into my face.
So it looks like the SELinux (or me myself?) has scrambled my harddisk.
I cannot even login anymore. The system is completely dead.
Some 'simple' questions:
Why did this go wrong?
What actually did go wrong?
What to do next? Re-install? That would be a bummer.

Thanks for the help.


From man selinux:

The  best  way  to  relabel the file system is to create the flag
file /.autorelabel and reboot. system-config-securitylevel, also has
this capability.  The restorcon/fixfiles commands are also available
for relabeling files.

As root, you will want to run something like: (This will reboot the
system when you enter the command, so make sure you are ready to

touch /.autorelabel ; reboot
touch /.autorelabel ; shutdown -r now

You could also just do the "touch /.autorelabel" and then reboot
using the GUI option to reboot the system.

This is the safest way to relabel since no processes are running when this happens. This causes the init script to run fixfiles relabel before it starts anything. If processes are already running, they could be running in the wrong context and creating files with the wrong
context until they are restarted.

Does this method clear out the /tmp directory when run? I usually clear the /tmp directory when I run fixfiles relabel from runlevel 1.

Since the same program is run during the boot autorelabel, I guess I can stop dropping to runlevel 1 to run the program. Thanks for the info about processes writing the wrong context until the restart.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]