RE: newrole in the background

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

 



My problem really had to do with our application passing strings as
arguments i.e. (echo "Hello World").  So we would lose our quoting.
Plus it just did not seem clean to mess with the argv pointers they way
that it did.

-----Original Message-----
From: Xavier Toth [mailto:txtoth@xxxxxxxxx] 
Sent: Wednesday, January 02, 2008 9:48 AM
To: Reed, Tim (US SSA)
Cc: Stephen Smalley; SE Linux
Subject: Re: newrole in the background

The arg thing is curious because I use newrole extensively and have
had no issue passing args.

On Dec 31, 2007 9:49 AM, Reed, Tim (US SSA) <tim.reed@xxxxxxxxxxxxxx>
wrote:
> I know you already applied this to the trunk, but here is another
patch.
>
>
> I cleaned up the handling of the -c argument.  Instead of messing with
> the argv that is passed in, I have it use a temp variable.  Plus if
the
> command that the user wants to run has command line args of its own
(ls
> -lrt /tmp), I push those into one value in the command line array.  I
> was having issues with the new shell that gets spawned off dropping
the
> command's arguments that I was trying to pass it.  So I would get an
> "ls" instead of "ls -lrt /tmp".  No quoting it did not work, as our
> application passes a string as an argument to the command.
>
> BTW which is the correct version to be working on 1.34.11 or 2.0.27?
>
> Thanks!
> Tim
>
> -----Original Message-----
> From: Stephen Smalley [mailto:sds@xxxxxxxxxxxxx]
> Sent: Friday, December 21, 2007 12:12 PM
> To: Xavier Toth
> Cc: Reed, Tim (US SSA); SE Linux
>
> Subject: Re: newrole in the background
>
>
> On Fri, 2007-12-21 at 10:31 -0600, Xavier Toth wrote:
> > Works for me, thanks.
>
> Ok, merged to trunk version of newrole.
>
> As usual, if you want something like this in an existing distro
release
> (e.g. RHEL5), you'll have to bugzilla it there and get it queued for
an
> update.
>
> >
> > On Dec 21, 2007 10:00 AM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:
> > >
> > > On Mon, 2007-12-17 at 12:40 -0800, Reed, Tim (US SSA) wrote:
> > > > Lets try this again....Patch Try #3
> > >
> > > This looks ok to me, although it doesn't apply cleanly on the
trunk,
> and
> > > the coding style still needs fixing (but I suppose make indent
will
> fix
> > > it up).
> > >
> > > Does anyone else have any comments on this?  Does it meet Ted's
need
> > > too?
> > >
> > > I tried running a program that detached the tty and then invoked
the
> > > patched newrole with a command, and as expected, if configured to
> use
> > > pam modules that required authentication, it just failed at that
> point
> > > with an authentication failed error, and otherwise, it proceeded
> without
> > > problem.
> > >
> > >
> > > > -----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
> > >
> > >
> --
> 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