Re: [systemd-devel] logind, su - sessions and initscripts compatibility
On Thu, 18.12.14 11:05, Andrei Borzenkov (arvidj...@gmail.com) wrote: As far as I know, systemd still officially retains compatibility with initscripts. Unfortunately, session management now at least partially broke it. Any initscript that is using su - would create logind session; this session will persist until processes started by initscript are runing. Any initscript that uses su - is broken I am very much convinced. For two reasons. First of all, the dash means that you want a login shell, i.e. one that feels like a real user login. That's very inappropriate for daemons. Secondly, su goes through the whole PAM stack. PAM is really for setting up user sessions, it has no place when setting up the environment for a daemon. If you want to set up the environment for a daemon, use start-stop-daemon, runuser, or simply systemd's User= setting. None of them goes through PAM. If you go through PAM, then you not only get a new systemd session opened for it, but also an audit session, selinux session, ... And you clearly don't want that. This is unfortunately little documented, but it's really how it is. Do not use su for init scripts. Never, ever. It's a user command, not a command to use in codepaths outside of user sessions. All this is wrong outside of the systemd context, and just a slightly bit more inside the systemd context, but the correct fix is certainly outside of the scope of systemd. Sorry, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] logind, su - sessions and initscripts compatibility
On Friday, December 19, 2014 at 07:58:11 PM, Andrei Borzenkov wrote:
В Fri, 19 Dec 2014 11:16:58 -0500
wor...@alum.mit.edu (Dale R. Worley) пишет:
Simon McVittie simon.mcvit...@collabora.co.uk writes:
On 18/12/14 14:10, Dale R. Worley wrote:
Simon McVittie simon.mcvit...@collabora.co.uk writes:
On 18/12/14 08:05, Andrei Borzenkov wrote:
Any initscript that is using su - would [cause badness]
Don't do that then? Init scripts are fairly clearly not login sessions.
Which init scripts do that?
More to the point, why would an initscript do that, since it's *already*
running as root?
su isn't just for becoming root; it can also cause transitions from root
to a less privileged user (su -c 'my-app-clear-cache' daemon is one
example of something that an init script might want to do).
Yeah, ack, that was my mistake. I was confusing su, su [user], and
su - [user]. But the question is about the su - [user] form, which
is basically intended to start a new login session (as far as I can see
from the man page), since it gives the user's shell a - in argv[0],
which is intended to instruct the shell to run the user's
initializations, etc.
Which means that the question I should have asked is Why would an
initscript use 'su -', as that is intended to start a new login
session?
There is not a single word about login session in su man page.
It says it starts login shell - but login session is not created by
shell so I do not see where you draw this conclusion from.
It's indirectly so.
This version of su uses PAM for authentication, account and session
management.
Maybe it's a problem of distro/integration? In current Arch, /etc/pam.d/su{,-l}
say
#%PAM-1.0
authsufficient pam_rootok.so
# Uncomment the following line to implicitly trust users in the wheel group.
#auth sufficient pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the wheel group.
#auth requiredpam_wheel.so use_uid
authrequiredpam_unix.so
account requiredpam_unix.so
session requiredpam_unix.so
, and su - my user started in systemd's debug shell seems to survive the
transition to rescue.target. Which is just as expected, because in this
configuration su does not register its sessions in logind.
(Please correct me if my analysis is wrong.)
--
Ivan Shapovalov / intelfx /
signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] logind, su - sessions and initscripts compatibility
Andrei Borzenkov arvidj...@gmail.com writes: There is not a single word about login session in su man page. It says it starts login shell - but login session is not created by shell so I do not see where you draw this conclusion from. The primary reason to use su - in this cases is a) get a clean environment and b) make started shell read usual startup files to ensure some known state for running programs. Actually the only difference between login and non login shells is which startup files are processed. I'm no expert in this, but as far as I know, there's no solid documentation or specification regarding login sessions as a concept. But as you say, the only difference between login and non login shells is which startup files are processed. And I take that to mean that when the login startup files are processed, the intention is to create a login session, to initialize everything as if the named user was logging in. Whereas what the non login startup files are processed, the intention is that this is *not* a new login, but rather an attempt to create a shell subprocess running under the new UID which is *not* disconnected from the environment of its parent process. And when an initscript does an su to get ready to run a daemon, it really ought to use the latter method, not the former. (I have written initscripts, so I know something about that.) I would expect the architects on the systemd project have thought about these problems more than I have. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] logind, su - sessions and initscripts compatibility
Simon McVittie simon.mcvit...@collabora.co.uk writes: On 18/12/14 14:10, Dale R. Worley wrote: Simon McVittie simon.mcvit...@collabora.co.uk writes: On 18/12/14 08:05, Andrei Borzenkov wrote: Any initscript that is using su - would [cause badness] Don't do that then? Init scripts are fairly clearly not login sessions. Which init scripts do that? More to the point, why would an initscript do that, since it's *already* running as root? su isn't just for becoming root; it can also cause transitions from root to a less privileged user (su -c 'my-app-clear-cache' daemon is one example of something that an init script might want to do). Yeah, ack, that was my mistake. I was confusing su, su [user], and su - [user]. But the question is about the su - [user] form, which is basically intended to start a new login session (as far as I can see from the man page), since it gives the user's shell a - in argv[0], which is intended to instruct the shell to run the user's initializations, etc. Which means that the question I should have asked is Why would an initscript use 'su -', as that is intended to start a new login session? Frederic Crozat fcro...@suse.com writes: Unfortunately, we don't always have a choice, when initscripts are not shipped as part of packages in the distribution but shipped by an ISV or a random external software :( And it seems that the answer is, They do that, even if we think they shouldn't. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] logind, su - sessions and initscripts compatibility
В Fri, 19 Dec 2014 11:16:58 -0500 wor...@alum.mit.edu (Dale R. Worley) пишет: Simon McVittie simon.mcvit...@collabora.co.uk writes: On 18/12/14 14:10, Dale R. Worley wrote: Simon McVittie simon.mcvit...@collabora.co.uk writes: On 18/12/14 08:05, Andrei Borzenkov wrote: Any initscript that is using su - would [cause badness] Don't do that then? Init scripts are fairly clearly not login sessions. Which init scripts do that? More to the point, why would an initscript do that, since it's *already* running as root? su isn't just for becoming root; it can also cause transitions from root to a less privileged user (su -c 'my-app-clear-cache' daemon is one example of something that an init script might want to do). Yeah, ack, that was my mistake. I was confusing su, su [user], and su - [user]. But the question is about the su - [user] form, which is basically intended to start a new login session (as far as I can see from the man page), since it gives the user's shell a - in argv[0], which is intended to instruct the shell to run the user's initializations, etc. Which means that the question I should have asked is Why would an initscript use 'su -', as that is intended to start a new login session? There is not a single word about login session in su man page. It says it starts login shell - but login session is not created by shell so I do not see where you draw this conclusion from. The primary reason to use su - in this cases is a) get a clean environment and b) make started shell read usual startup files to ensure some known state for running programs. Actually the only difference between login and non login shells is which startup files are processed. Frederic Crozat fcro...@suse.com writes: Unfortunately, we don't always have a choice, when initscripts are not shipped as part of packages in the distribution but shipped by an ISV or a random external software :( And it seems that the answer is, They do that, even if we think they shouldn't. Please give a link to systemd documentation where it says you should not do it. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] logind, su - sessions and initscripts compatibility
As far as I know, systemd still officially retains compatibility with initscripts. Unfortunately, session management now at least partially broke it. Any initscript that is using su - would create logind session; this session will persist until processes started by initscript are runing. On shutdown logind is stopped early; it also tears down all user sessions killing all processes in these sessions. So initscripts do not even get chance to initiate clean termination of running services. The only solution I can think of is to make pam_systemd skip session based on some environment variable which would be set by sysvinit generator. Would that be acceptable? Any other idea? Details are e.g. here: http://bugzilla.suse.com/show_bug.cgi?id=906900#c34. I now think this explains several other similar cases reported in the past. Thank you! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] logind, su - sessions and initscripts compatibility
On 18/12/14 08:05, Andrei Borzenkov wrote: Any initscript that is using su - would [cause badness] Don't do that then? Init scripts are fairly clearly not login sessions. Which init scripts do that? In Debian, our init scripts would typically use start-stop-daemon --chuid whateveruser --start whateverd instead of su. Does your distribution have an equivalent? I'm gradually forming the opinion that su should be considered deprecated for both its roles (interactive privilege escalation/privilege-dropping for one-off commands or interactive shells, and automated uid swapping), because it doesn't do either of them particularly well; in particular, it doesn't sanitize environment variables by default (you have to remember the - which has other side-effects), and the need for the command to be a shell command-line rather than an argument vector makes it hard to use securely. sudo/pkexec/etc. make good replacements for su - for interactive use, and something like start-stop-daemon or chroot --userspec=whateveruser / -- command (with recent coreutils) can replace su for automated uid swapping. Both of these make it easy to do something like subprocess.call(['sudo', '--', executable] + argv) without needing to involve a shell at all, and if you do need to evaluate shell syntax, subprocess.call(['sudo', '--', '/bin/sh', '-c', shellcommandline]) solves that for you. (For non-Python users: replace subprocess.call with your favourite way to execute a command specified with an executable and an array of arguments, such as g_spawn_async().) S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] logind, su - sessions and initscripts compatibility
Simon McVittie simon.mcvit...@collabora.co.uk writes: On 18/12/14 08:05, Andrei Borzenkov wrote: Any initscript that is using su - would [cause badness] Don't do that then? Init scripts are fairly clearly not login sessions. Which init scripts do that? More to the point, why would an initscript do that, since it's *already* running as root? Though I'm sufficiently out of the loop regarding the architecture that I don't see how su can have such complexities -- As far as I know, its purpose is to create a subprocess whose UID is different from the UID of this process; in no way is it intended to be a separate login. Why would shutting down logind suddenly cause one of my subprocesses to vanish? Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] logind, su - sessions and initscripts compatibility
On 18/12/14 14:10, Dale R. Worley wrote: Simon McVittie simon.mcvit...@collabora.co.uk writes: On 18/12/14 08:05, Andrei Borzenkov wrote: Any initscript that is using su - would [cause badness] Don't do that then? Init scripts are fairly clearly not login sessions. Which init scripts do that? More to the point, why would an initscript do that, since it's *already* running as root? su isn't just for becoming root; it can also cause transitions from root to a less privileged user (su -c 'my-app-clear-cache' daemon is one example of something that an init script might want to do). Though I'm sufficiently out of the loop regarding the architecture that I don't see how su can have such complexities -- As far as I know, its purpose is to create a subprocess whose UID is different from the UID of this process; in no way is it intended to be a separate login. If this was ever true, it ceased to be true when su started running PAM modules. This is what I meant about su having multiple roles, and not being particularly good at any of them... S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] logind, su - sessions and initscripts compatibility
Am 18.12.2014 um 15:10 schrieb Dale R. Worley: Simon McVittie simon.mcvit...@collabora.co.uk writes: On 18/12/14 08:05, Andrei Borzenkov wrote: Any initscript that is using su - would [cause badness] Don't do that then? Init scripts are fairly clearly not login sessions. Which init scripts do that? More to the point, why would an initscript do that, since it's *already* running as root? because su means switch user and is not limited to root ExecStartPre can exist more then once and be invoked as different users to prepare start of a complex service instead multiple units signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] logind, su - sessions and initscripts compatibility
2014-12-18 13:19 GMT+01:00 Simon McVittie simon.mcvit...@collabora.co.uk: On 18/12/14 08:05, Andrei Borzenkov wrote: Any initscript that is using su - would [cause badness] Don't do that then? Init scripts are fairly clearly not login sessions. Which init scripts do that? In Debian, our init scripts would typically use start-stop-daemon --chuid whateveruser --start whateverd instead of su. Does your distribution have an equivalent? I'm gradually forming the opinion that su should be considered deprecated for both its roles (interactive privilege escalation/privilege-dropping for one-off commands or interactive shells, and automated uid swapping), because it doesn't do either of them particularly well; in particular, it doesn't sanitize environment variables by default (you have to remember the - which has other side-effects), and the need for the command to be a shell command-line rather than an argument vector makes it hard to use securely. I remember that util-linux added a runuser utility [1] which is supposed to be more suitable to run processes under certain gid/uids from within scripts. [1] http://linux.die.net/man/1/runuser -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] logind, su - sessions and initscripts compatibility
Le jeudi 18 décembre 2014 à 12:19 +, Simon McVittie a écrit : On 18/12/14 08:05, Andrei Borzenkov wrote: Any initscript that is using su - would [cause badness] Don't do that then? Init scripts are fairly clearly not login sessions. Which init scripts do that? Unfortunately, we don't always have a choice, when initscripts are not shipped as part of packages in the distribution but shipped by an ISV or a random external software :( -- Frederic Crozat Project Manager Enterprise Desktop SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
