On 5/26/2010 5:16 PM, Gordon Messmer wrote:
Isn't the context associated with the program itself, not its parent?
The context is inherited from the process which calls exec() if there is no transition defined. If there is a transition, it is associated with the path.
Is this documented anywhere?
Yes, this is the documented behavior of domain transitions.
I meant, is it documented that the domain transitions are specified on the init scripts only, not the actual programs they start? Or is that a quirk of this particular case? It's not unusual at all for an administrator to run the init scripts directly, perhaps with 'sh -x' to see the values that are expanded in the commands. I doubt if many people that trust SElinux would realize that would leave them unprotected.
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.
From what he has posted so far the "whatever he did" was starting smbd directly
from a root command line or running the init script with 'sh' or 'bash'.
I meant whatever he did to create /etc/init.d/smbd with an SELinux label other than the one that rpm originally placed on it. He wasn't specific about how or where the file was created. It had a label on it which caused a transition to an SELinux domain other than unconfined or the one normally used by smbd.
My impression was that the usual invocation of /etc/init.d/smbd (via "service" or directly without 'sh ...' _did_ give the expected context and his problems were from files smbd subsequently could not access, whereas running smbd directly or using 'sh ' on the script made it work anyway.