Lets try this again....Patch Try #3 -----Original Message----- From: owner-selinux@xxxxxxxxxxxxx [mailto:owner-selinux@xxxxxxxxxxxxx] On Behalf Of Stephen Smalley Sent: Monday, December 17, 2007 11:10 AM To: Reed, Tim (US SSA) Cc: Xavier Toth; SE Linux Subject: RE: newrole in the background 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.
Attachment:
newrole_no_tty_3.patch
Description: newrole_no_tty_3.patch
