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.
Regards,
Jeroen.
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
reboot!):
touch /.autorelabel ; reboot
or
touch /.autorelabel ; shutdown -r now
You could also just do the "touch /.autorelabel" and then reboot
using the GUI option to reboot the system.
Mikkel
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.
Jim
