[CentOS] Odd failure of smbd to start from init.d - CentOS 5.4 - it's that fine SELinux

[Gordon Messmer]

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.