Re: Another system management tool to disappear.
Hi.
On Sat, 29 Aug 2015 08:55:00 -0400
Gene Heskett <gheskett@wdtv.com> wrote:
> On Saturday 29 August 2015 06:18:56 Reco wrote:
>
> > Hi.
> >
> > On Sat, 29 Aug 2015 11:49:12 +1200
> >
> > Chris Bannister <cbannister@slingshot.co.nz> wrote:
> > > On Fri, Aug 28, 2015 at 07:12:32PM +0300, Reco wrote:
> > > > To:
> > > >
> > > > Well, there have been long discussions about this, but the problem
> > > > is that what "su" is supposed to do is very unclear. On one hand
> > > > it's supposed *to open a new session* and change a number of
> > > > execution context parameters (uid, gid, env, ...), and on the
> > > > other it's supposed to inherit a lot concepts from the originating
> > > > session (tty, cgroup, audit, ...).
> > > >
> > > >
> > > > I'm kind of surprised that the bug was not closed as WONTFIX.
> > > > su(1) is not a "full login", but it's not supposed to provide one
> > > > anyway.
> > >
> > > su - <name>
> > >
> > > Has always worked fine for me. What's the problem?
> >
> > https://github.com/systemd/systemd/issues/825 says:
> >
> > su[1980]: pam_systemd(su-l:session): Cannot create session: Already
> > running in a session
> >
> > Why the bug report implies that pam_systemd shoud create a new
> > 'session' (whatever it means by 'session') *and* set some obscure
> > environment variables is beyond me. Especially since su(1) directly
> > says that su should not create session, it should reuse an existing
> > one.
> >
> Now I am again confused. As the admin for my 4 machine home network,
> there are things that run as other users, so I'll use amanda, the backup
> program as an example here.
Welcome to the club. I'm confused by this bugreport too.
> In order to adjust any of its configuration, and do it without mucking
> with file ownerships & permissions, I much first do a sudo -i to make me
> an immortal root. Then I can either "su amanda", or su amanda -c "geany
> filename" so that for the duration of that commands execution, I am the
> user amanda. Some distro's setup a "backup" group and make amanda a
> member, but those distro's do not always preserve the amanda tenet of
> running with just enough permissions to get the job done, so I tend to
> steer clear and only install from the tarball.
>
> My web page in the sig is also on this machine, all running in another
> users sandbox, so again to manage that, I have to do the 'become root'
> bit, then edit and keep track of perms with chown/chmod which I can only
> do with the sudo -i phantom roor.
Kind of old-fashioned for my taste (I'd use 'sudo -u' in the first
place), but perfectly sane approach.
> If su goes away, IMNSHO, it will be such a PITA that it will encourage
> far more people to just give up and run their machines as root full
> time. And I don't believe for a millisecond that is the effect
> intended.
They provide some systemd-specific kludge instead of su. So it's not
that bad.
And, given the current systemd adoption rate in Debian, I'd say that
we, stable users, have 3-4 years before that "machinectl login" thing
will be available to us.
> So, if su goes away, how do I accomplish those tasks in a suitable
> manner that will not bore a hole in the user sandbox?
If it comes to this (i.e 'su' will go away) - I just use busybox
(which has perfectly working implementation of su without the fancy
bits). I.e.
busybox su -
Reco
Reply to: