RE: newrole in the background

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

 



On Mon, 2007-12-17 at 08:01 -0800, Reed, Tim (US SSA) wrote:
> When newrole goes and grabs the ttyname, if it cannot get one should it
> still log something to the screen or not?
> 
> Currently it says "Error! Could not retrieve tty information".  I was
> thinking of changing Error to Warning.

Yes, that's fine.
> 
> What is the recommendation here?
> Also do you have the coding standards posted somewhere?

We just loosely follow kernel coding style,
http://lxr.linux.no/linux/Documentation/CodingStyle
and make indent can be used as a hammer (but not a very good one).

> 
> -----Original Message-----
> From: Stephen Smalley [mailto:sds@xxxxxxxxxxxxx] 
> Sent: Thursday, December 13, 2007 12:40 PM
> To: Reed, Tim (US SSA)
> Cc: Xavier Toth; SE Linux
> Subject: RE: newrole in the background
> 
> On Thu, 2007-12-13 at 09:06 -0800, Reed, Tim (US SSA) wrote:
> > New patch...I have added checks around the calls that deal with the
> tty.
> > So if ttyn is an empty string (something had a heartache with it being
> > NULL) then it skips the processing.  It does appear to work but more
> > testing is needed.  Please review and comment.
> 
> Patch is reversed, and doesn't seem to be complete (test for a NULL
> ttyname still remains and is fatal in main).
> 
> ttyn should really be NULL if not defined - just fix the code.  Cleaner
> and faster to test for NULL than for empty string.  Looks like
> authenticate_via_pam() needs a check.
> 
> You can simplify the logic a fair amount, e.g. on entry to relabel_tty()
> and restore_tty_label(), just do a if (!ttyn) return 0;
> 
> Coding style doesn't match.
> 
> > Now say if someone ran `newrole -l SystemHigh -- -c "su - foo"` in the
> > background of a script, you would not be able to give su input as it
> is
> > in the background and has no tty.  su in this case exits gracefully I
> > guess you could say.  
> > 
> > My point is that if you have an application that needs to run from
> > newrole, in the background AND requires user input, you will not be
> able
> > to give the application input while it is in the background and have
> it
> > work successfully.
> 
> You can't do that anyway, by definition.
> 
> > Example:
> > foo.sh
> > ---------------
> > #!/bin/bash
> > 
> > ./bar.sh &
> > ---------------
> > bar.sh
> > ---------------
> > #!/bin/bash
> > 
> > su - root -c /bin/date
> > ---------------
> > 
> > su exits because there is no tty for input.  So is chasing down having
> > newrole run in a pseudo tty in the background and accept input worth
> the
> > time?
> 
> It doesn't help - there is no input to accept.
> 
> We just need to make sure that the pam modules and chkpwd don't block
> forever or seg fault when handed a NULL PAM_TTY.
> 
-- 
Stephen Smalley
National Security Agency


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