All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Reisner <d@falconindy.com>
To: "Karel Zak" <kzak@redhat.com>,
	util-linux <util-linux@vger.kernel.org>,
	"Ludwig Nussel" <ludwig.nussel@suse.de>,
	"Pádraig Brady" <P@draigBrady.com>
Subject: Re: runuser(1) and su(1) -g/-G
Date: Wed, 5 Sep 2012 17:28:04 -0400	[thread overview]
Message-ID: <20120905212804.GD1899@rampage> (raw)
In-Reply-To: <20120905123822.GZ1899@rampage>

On Wed, Sep 05, 2012 at 08:38:22AM -0400, Dave Reisner wrote:
> On Tue, Sep 04, 2012 at 05:18:43PM +0200, Karel Zak wrote:
> > 
> >  Hi,
> > 
> > I did some changes to the su(1):
> > 
> >   - add --group= option to specify the primary group
> >   - add --supp-group= option to specify a supplemental group
> > 
> > the both options are based on Fedora runuser(1) patch and it's
> > available for root only (non-root cannot specify any groups).
> > 
> > 
> > I have also added new command runuser(1) -- it's completely based on
> > su(1) code. The difference is that runuser does not ask for password,
> > has to be executed by root and it uses different PAM configuration
> > (/etc/pam.d/runuser[-l]).
> > 
> > The changes should be available in v2.23 (or easily backported to
> > 2.22, I'll do that for Fedora).
> > 
> > See master branch and "git whatchanged login-utils/".
> > 
> >     Karel
> > 
> 
> Hi Karel,
> 
> I think we're missing out on an opportunity with runuser. su insists on
> starting a shell which, among other subtle problems, leads to the
> largeer problem of quoting and escaping the command passed to the -c
> flag. I think we should do something like this:
> 
> - separate out argument parsing to runuser and su
> - remove most of the flags from runuser (-f, -c, -l, -, -s), add a -u
>   flag (optional, for user)
> - create a single common entry point for creating a session
> - separate out the run command logic
> 
> With a name like runuser, I would expect that its purpose would be to
> simply run commands (and not necessarily get a shell for a user, as is
> done with su). runuser could take non-option arguments as argv for the
> new command so that we'd have examples like this:
> 
>   runuser -u notroot vi /etc/fstab
>   runuser notroot foocmd embedded '"quotes"'
>   runuser -u notroot foocmd has args "with spaces" sometimes
> 
> If you still desperately want to abuse the command to create a shell for
> a user, then you just do that:
> 
>   runuser -u notroot -- /bin/sh -
> 
> I can't make any guarantees that I'll be able to offers patches for this
> myself, but I'll definitely be taking a look if I have some free time.
> Just thought I'd bring up the idea, since it's always been a pet peeve
> of mine to fix if ever there were an opportunity for a mulligan on su
> (and this is it!).
> 
> Cheers,
> Dave

Hrmm... I had no idea that runuser was an existing command in the RedHat
world, which makes my idea of a "mulligan" less feasible. Boo.


  reply	other threads:[~2012-09-05 21:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-04 15:18 runuser(1) and su(1) -g/-G Karel Zak
2012-09-04 19:52 ` Pádraig Brady
2012-09-05  8:44   ` Karel Zak
2012-09-05 12:38 ` Dave Reisner
2012-09-05 21:28   ` Dave Reisner [this message]
2012-09-07 12:07     ` Karel Zak
2012-09-07 12:39       ` Pádraig Brady
2012-09-07 13:09         ` Adam Sampson
2012-09-13 10:12         ` Karel Zak
2012-09-07 12:47       ` Dave Reisner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120905212804.GD1899@rampage \
    --to=d@falconindy.com \
    --cc=P@draigBrady.com \
    --cc=kzak@redhat.com \
    --cc=ludwig.nussel@suse.de \
    --cc=util-linux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.