All of lore.kernel.org
 help / color / mirror / Atom feed
From: Karel Zak <kzak@redhat.com>
To: 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: Fri, 7 Sep 2012 14:07:16 +0200	[thread overview]
Message-ID: <20120907120716.GD23242@x2.net.home> (raw)
In-Reply-To: <20120905212804.GD1899@rampage>

On Wed, Sep 05, 2012 at 05:28:04PM -0400, Dave Reisner wrote:
> > 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:

 good point

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

 well, we still need to initialize the session and it would be also
 to have independent PAM setting for "login-like-session" (-l - options).

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

 well, but it will NOT use /etc/pam.d/runuser-l

 I agree that -f -s -c are unnecessary (and -c is wrong at all...). It
 would be probably better to support:

    runuser [-u] notroot [<command> [arg]]

 and if <command> is not specified then start a shell, and if -l is
 specified create a login-like session.

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

 Well, that's question if we (upstream) have to care about one crazy
 distro specific command. Maybe we can introduce a new command (with a
 different name) and ignore the original runuser. For good reason the
 command has not been accepted by coreutils upstream.

 Any suggestion for the new name?

    runuid
    runid
    execuser

 I have no problem to revert the runuser patch, really ;-) It was
 probably too hasty decision to merge whole my su branch.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

  reply	other threads:[~2012-09-07 12:07 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
2012-09-07 12:07     ` Karel Zak [this message]
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=20120907120716.GD23242@x2.net.home \
    --to=kzak@redhat.com \
    --cc=P@draigBrady.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.