Re: newrole in the background

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



We ended up creating a variant of newrole which doesn't require tty
access. We did this to run some of our applications in the background
but still get newroles ability to set the context/level of the child
and to create a pam session for polyinstantiation. For this to work we
had to configure our apps into our variants equivalent of
/etc/selinux/newrole_pam.conf and provide corresponding /etc/pam.d
files which typically look like :
#%PAM-1.0
auth       required     pam_permit.so
account    required     pam_permit.so
password   required     pam_permit.so
session    required     pam_mkpolydir.so debug
session    required     pam_namespace.so unmnt_remnt
no_unmount_on_close gen_hash ignore_instance_parent_mode debug

This variant was based on a Fedora policysoreutils source rpm because
the RHEL5 version doesn't contain the code to map applications to
/etc/pam.d files using /etc/selinux/newrole_pam.conf.

On Dec 11, 2007 9:21 AM, Reed, Tim (US SSA) <tim.reed@xxxxxxxxxxxxxx> wrote:
>
>
>
>
> I am currently running RHEL 5 update 1 with the MLS policy.
>
>
>
> The issue that I am now having is that in our code we switched over from
> using runcon to newrole.  The newrole command is executed from within our
> application that is running in the background, so no TTY.  Which is the
> problem.
>
>
>
> Newrole bombs because there is no tty, the call that "fails" is ttyname(0).
>
>
>
> Any suggestions on a workaround or fix?
>
>
>
> I have created a test set of scripts to duplicate the issue
>
>
>
>
> foo.sh
>
> ##########################
>
> #!/bin/bash
>
>
>
> #show the current tty name
>
> printf "caller tty: "
>
> tty
>
>
>
> ./bar.sh &
>
>
>
> ##########################
>
>
>
> bar.sh
>
> ##########################
>
> #!/bin/bash
>
>
>
> #show the current tty name
>
> printf "newrole tty: "
>
> tty
>
>
>
> newrole –l SystemHigh -- -c "ls /var"
>
>
>
> ##########################
>
>
>
> Thanks,
>
> Tim


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.

[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux