Hi. On Sat, 29 Aug 2015 08:55:00 -0400 Gene Heskett <ghesk...@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 <cbannis...@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
