On 05/25/2010 06:44 PM, Whit Blauvelt wrote: > > And that still doesn't say why it starts having a problem with > /var/cache/samba/messages.tbd. Does it? That's simply the first file which was denied by policy. If that one had been removed, the next one would have caused problems. >> That file can be deleted and will be recreated on smbd start, it's >> just a cache file. > > So in theory if I'd nuked that file smbd would have been happy? No. With that file removed, smbd probably wouldn't have been able to write to the directory. If it was able to, it probably would have run into trouble with the next file. If smbd started up in the context which was configured for it, everything would work normally. If smbd started up in the "unconfined" context, everything would work normally (but not benefit from SELinux security). The problem appears to be that smbd was starting in some other context, which you haven't shared. > Then why was it also happy with "sh /etc/init.d/smb start" but not > "/etc/init.d/smb start". I'm happy to become more educated on this. But if > invoking a major daemon startup that selinux wants to block is as easy as > that, selinux is window dressing, not security. Your misunderstanding seems to be that SELinux is not intended to prevent an attacker who has root privileges on your system from starting smbd. Instead, it is intended to confine the smbd that the system's administrator is running from taking actions which are not allowed by policy. That is to say that SELinux does not "want" to block smbd from running. SELinux is intended to describe the access that system daemons like smbd should have in greater detail than mere filesystem access, and to confine smbd to that behavior. Whatever you did caused smbd to start up in some other context (but not unconfined), and was thus confining smbd to the behavior that was appropriate for some other process. It should be obvious why that would cause problems.