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.
As far as setroubleshoot telling you to "chcon -R -t sama_share_t /";
this should be fixed in the latest
setroubleshoot setroubleshoot-1.9.4-2.fc7
There is a check in there to make sure it does not match any of the
default paths in the filesystem rpm, including
/.
If you have this setroubleshoot package installed then this is a bug.
So when I restart my system and relabel on the next boot, then I should
be patient for a while (a day?). Is this also the reason why I can't login?
The system has no harddisk LED on the outside so I cannot determine when
it's ready relabeling or if it's doing anything at all.
Regards,
Jeroen.
