su user -c problem

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eric Paris wrote:
> On Mon, 2008-01-07 at 11:23 -0500, Gene Heskett wrote:
>> On Monday 07 January 2008, Eric Paris wrote:
>>> On Mon, 2008-01-07 at 03:19 -0500, Gene Heskett wrote:
>>>> On Sunday 06 January 2008, Todd Zullinger wrote:
>>>>> Gene Heskett wrote:
>>>>>>> I've got similar things in /etc/rc.local that used to use su -c.  I
>>>>>>> don't recall having them get denied outright, but the programs that
>>>>>>> were run definitely didn't pick up the proper SELinux contexts.  So I
>>>>>>> now have a few entries like this:
>>>>>>>
>>>>>>> runcon user_u:system_r:unconfined_t -- runuser -l -c "screen -dm" tmz
>>>>>> I'm afraid I have pretty close to a NDI what that will do, Todd.
>>>>>> And your use of the words 'used to' above also tells be your are
>>>>>> doing this su user -c function differently now.  Can you elaborate?
>>>>>> The manpage for runcon is so concise as to be obtuse.
>>>>> I noticed that the processes I started with su -c didn't have the
>>>>> proper SELinux contexts, so that's why I added the runcon call.  It
>>>>> sets up the processes to use the same contexts as they would get if I
>>>>> had logged in as tmz and run them (AFAIK).  Using runuser is very
>>>>> similar to using su.  I don't know if you'd have any problems using su
>>>>> instead of runuser or not.  I'm far from knowledgeable on the subject.
>>>>>
>>>>>> Here is the line in question, in rc.local, that does not now work:
>>>>>>
>>>>>> su gene -c "fetchmail -d 90 --fetchmailrc /home/gene/.fetchmailrc"
>>>>>>
>>>>>> Can you translate that into a 'runcon' style line please?
>>>>> Sure.  (No guarantees that this is the best or most correct way. :)
>>>>>
>>>>> runcon user_u:system_r:unconfined_t -- runuser -l -c "fetchmail -d 90"
>>>>> gene
>>> for F8 I think it should be "unconfined_u:system_r:unconfined_t"  for
>>> rawhide i think it is "unconfined_u:unconfined_r:unconfined_t"
>> and both of those return "invalid context" and fetchmail is not started.
> 
> ahh, yeah, i should have paid more attention to the suggestion you were
> given on how to use runcon and read the man page again.
> 
> runcon -t unconfined_t -- whatever you want to run.
> 
> I think i'll have a little chat with dan about this stuff....
> 
> 
>>> I don't really understand the rest of what you are asking...  typically
>>> we on list like to see the output of ausearch -m AVC -ts recent or some
>>> other form of the raw denial (its at the bottom of the setroubleshoot
>>> output) so we actually know what is failing.
>> That output of "ausearch -m AVC -ts recent" is empty, as is the
>> setroubleshoot screen after running rc.local three times just now.
>>
>> The larger problem ATM is that rc.local is NOT being executed at the
>> end of the bootup.  And yet:
> 
> I'm at a total loss on this one, did it execute on boot up if you add
> enforcing=0 to the kernel boot line?
> 
> -Eric
> 
> --
> fedora-selinux-list mailing list
> fedora-selinux-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
You are missing the s0 at the end

runcon user_u:system_r:unconfined_t:s0 -- runuser -l -c "fetchmail -d 90"

runcon -t unconfined_t -- runuser -l -c "fetchmail -d 90"

Would also work.

Why are you doing this though?  Is this because fetchmail runs under a
context that SELinux is preventing when run from init?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkeCZowACgkQrlYvE4MpobPF5QCeJmNt5AAN6AwRbU5L6cQECyjz
2c4An1fsyV9VuksIL1fFPNJnQa7ZTlFQ
=p9u2
-----END PGP SIGNATURE-----