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@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
