On Saturday 29 August 2015 09:24:52 Reco wrote: > 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.
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>
