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