su user -c problem
 

Greetings;

For years, I have been starting fetchmail as a background daemon by having the
line:
su user -c "fetchmail -d etc etc" in my rc.local script.

Forced to re-install because something wiped the partition table on my boot
drive, I installed F8 and I believe its was uptodate as of last night.

But, its not running anymore via that procedure, and setroubleshoot's gui will
display that it was denied at the time of the boot.

It still works perfectly if I cut/paste that line into a root shell after I'm
logged in.

How can I address this?

I've also bz'd it.

--
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)
I've found my niche. If you're wondering why I'm not there, there was
this little hole in the bottom ...
-- John Croll

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

su user -c problem
 

Gene Heskett wrote:
> For years, I have been starting fetchmail as a background daemon by
> having the line:
> su user -c "fetchmail -d etc etc" in my rc.local script.
>
> Forced to re-install because something wiped the partition table on
> my boot drive, I installed F8 and I believe its was uptodate as of
> last night.
>
> But, its not running anymore via that procedure, and
> setroubleshoot's gui will display that it was denied at the time of
> the boot.
>
> It still works perfectly if I cut/paste that line into a root shell
> after I'm logged in.
>
> How can I address this?

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

--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~
There's no trick to being a humorist when you have the whole
government working for you.
-- Will Rogers.

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

su user -c problem
 

On Sunday 06 January 2008, Todd Zullinger wrote:
>Gene Heskett wrote:
>> For years, I have been starting fetchmail as a background daemon by
>> having the line:
>> su user -c "fetchmail -d etc etc" in my rc.local script.
>>
>> Forced to re-install because something wiped the partition table on
>> my boot drive, I installed F8 and I believe its was uptodate as of
>> last night.
>>
>> But, its not running anymore via that procedure, and
>> setroubleshoot's gui will display that it was denied at the time of
>> the boot.
>>
>> It still works perfectly if I cut/paste that line into a root shell
>> after I'm logged in.
>>
>> How can I address this?
>
>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.

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?

Thanks.

--
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)
Failure is not an option -- it comes bundled with Windows.

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

su user -c problem
 

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.)

--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~
The kind of man who wants the government to adopt and enforce his
ideas is always the kind of man whose ideas are idiotic.
-- H. L. Mencken

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

su user -c problem
 

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

su user -c problem
 

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"

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.

-Eric

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

su user -c problem
 

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.

>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:

root@coyote ~]# ls -l /etc/rc.d/rc3.d/S99local
lrwxrwxrwx 1 root root 11 2008-01-04 22:39 /etc/rc.d/rc3.d/S99local -> ../rc.local

and
[root@coyote ~]# ls -lZ /etc/rc.d/rc3.d/S99local
lrwxrwxrwx root root system_u:object_r:etc_t:s0 /etc/rc.d/rc3.d/S99local -> ../rc.local

and
[root@coyote ~]# ls -lZ /etc/rc.d/rc.local
-rwxr-xr-x root root system_u:object_r:initrc_exec_t:s0 /etc/rc.d/rc.local

I boot and login at runlevel 3, the everything but X, then run startx by hand.
I'm a big dummy maybe, and an old fart, but *I* can run it by using the
S99local link exactly the same as it real name, so why doesn't init run it?

I should be seeing in my login console, all of this:
------------
[root@coyote ~]# /etc/rc.d/rc.local
/root/bin:/usr/lib/qt-3.3/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/lib/ccache:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin:/usr/local/bin
/usr/local/mozilla /usr/lib/qt-3.3
restoring audio settings
starting heyu
heyu_engine is running - use 'heyu restart' to reconfigure
CM11A clock set to Mon, 11:03:52 (Standard Time), Day 6
Emulating macro Dawn_Off at address 1013
heyu started
LATITUDE=39:41 LONGITUDE=80:17
starting fetchmail
user_u:system_r:unconfined_t is not a valid context
starting drift-checker
adding shop.coyote.den to xhost access list
5279 ttyUSB0 00:00:00 heyu
5281 ? 00:00:38 heyu
20736 ? 00:00:00 heyu
4097 ? 00:00:04 fetchmail
restoreing midi playback to Audigy 2 card
setup env for nitros9 development
ssh
/opt/os9
--------------
But I am not.

Thanks Eric.



--
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)
"Don't hate me because I'm beautiful. Hate me because I'm beautiful, smart
and rich."
-- Calvin Keegan

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

su user -c problem
 

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

su user -c problem
 

-----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@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

iEYEARECAAYFAkeCZowACgkQrlYvE4MpobPF5QCeJmNt5AAN6A wRbU5L6cQECyjz
2c4An1fsyV9VuksIL1fFPNJnQa7ZTlFQ
=p9u2
-----END PGP SIGNATURE-----

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

su user -c problem
 

On Monday 07 January 2008 05:23:20 pm Gene Heskett wrote:

> I boot and login at runlevel 3, the everything but X, then run startx by
> hand. I'm a big dummy maybe, and an old fart, but *I* can run it by using
> the S99local link exactly the same as it real name, so why doesn't init run
> it?

I had something similar happen to me some time in the past, say about Fedora
Core 3, and my init script was hanging (I could see it with pstree) asking
for user input. I would pepper the script with

echo $$ so far so good >> /tmp/cursed-initscript.log

to see if it is started at all and then hangs or exits somewhere.

Davide Bolcioni
--
There is no place like /home.

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list