su user -c problem

[Gene Heskett]

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
>
>(I think I'd remove the --fetchmailrc option since ~/.fetchmailrc is
>the default and using the -l option to runuser will make the command
>run as gene, so ~/.fetchmailrc will be /home/gene/.fetchmailrc.  But
>that shouldn't matter at all in regards to SELinux.)

Now I have a more pressing problem.  If I exec that file after booting and 
logging in I get a bunch of rejects from several things I tried to convert so 
they weren't running as root, like heyu, so I took those back out, but the 
fetchmail line says this:

starting fetchmail
user_u:system_r:unconfined_t is not a valid context
And fetchmail is not running.

But the bigger problem is that according to the trace I can see by shift 
pageup as soon as I log in from a fresh reboot, there is absolutely nothing 
showing to indicate that S99local ever ran, nothing in that file is echoed or 
performed.  setroubleshooter is also silent on the subject. 

I can post this rc.local if you'd like.

An ls -lZ on it:
-rwxr-xr-x  root root system_u:object_r:initrc_exec_t:s0 /etc/rc.d/rc.local

And I just did an autorelabel.  I've been following setroubleshooter's advice 
& doing the semanage things too so hopefully I won't need to do them again.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Please don't recommend me to your friends-- it's difficult enough to
cope with you alone.