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

Re: Another system management tool to disappear.



On Saturday 29 August 2015 09:24:52 Reco wrote:

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

ISTR I read that someplace, tried it, but it needed a root password, 
which does not exist on any of these machines, hence the "two stage" 
approach to getting the job done.

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

I don't recall recognizing that being discussed yet.

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

Command not found. Wheezy 32 bit install.

Thanks.
>
> Reco


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>


Reply to: