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. -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
