On 05/25/2010 10:44 PM, Les Mikesell wrote: > > That still doesn't explain why there is a difference in smbd's context when its > parent is an explicitly started shell vs. the implict one that starts when the > script file is executed. SELinux domain transitions are handled by the kernel. If you call exec() with a path which has a domain transition specified, the kernel will transition to the specified domain as part of the exec() call. What that means here is that /etc/init.d/smbd has a domain transition specified. If you were to call exec() with that path (as your shell will when you enter that path alone and hit Enter), the kernel receives your exec() request, examines the path given, determines that a transition is defined, and transitions to the new domain as it creates the new process. Now, if you call exec() with /bin/sh as the path and /etc/init.d/smbd as an arg (as your shell will when you enter "/bin/sh /etc/init.d/smbd" and hit Enter), the kernel will check for a domain transition on /bin/sh and load that program. The kernel has no knowledge that sh will load instructions from /etc/init.d/smbd and execute them any more than it would if you were to run "/bin/sh < /etc/init.d/smbd" in a shell. It can't determine that it should transition to the domain on that file, so the process inherits whatever domain called "/bin/sh" (probably the unconfined domain). > 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. > >> 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.