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

[Les Mikesell]

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.

-- 
   Les Mikesell
    lesmikesell at gmail.com