Am 27.03.2017 um 17:07 schrieb Marc Haber: > Hi Felipe, > > thanks for your fast answer. I really appreciate your consideration. > > On Mon, Mar 27, 2017 at 11:47:40AM -0300, Felipe Sateler wrote: >> On Mon, Mar 27, 2017 at 5:51 AM, Marc Haber >> <[email protected]> wrote: >>> (1) allow regular login in emergency mode >>> Instead of using sulogin in the emergency target, one could use a >>> regular login process which would allow logging in as a regular user >>> and use sudo to get root privileges. I do admit that systems can be so >>> broken that sudo won't work, but being deprived of the actual _chance_ >>> for that to work is frustrating. >> >> I suppose this would be as simple as replacing the `ExecStart` >> directives of `emergency.service` to invoke login instead of sulogin. >> Or the new[1] script could be enhanced to read that configuration from >> somewhere. >> >> [1] https://github.com/systemd/systemd/pull/5623 > > I like the idea of a configurable script. But I also like the idea of > having an emergency-login.service which could be used as a drop-in > replacement, keeping emergency.service simple. But, it looks like, it > is not as simple any more anyway. > > I am however worried that sulogin is used here instead of login for a > reason. Does anybody reading thie remember why sulogin was invented in > the first place? I have never understood why one would restrict login > in this mode of operation.
You don't want to involve the whole PAM stack in an emergency situation. PAM can be almost arbitrarily complex, involving network services (LDAP, SSSD, etc.) >>> (2) try to bring the network up and start an (emergency) sshd >>> I have had cases where the system boot was aborted because /var could >>> not be mounted. In those cases, it would have been possible to ssh in >>> if the system had bothered to try starting sshd. This used to be the >>> case in the pre-systemd era, and I'd love to get this possibility back. >> >> I don't think this can work as long as ssh.service has >> `DefaultDependencies=yes`, because that implies >> `Requires=sysinit.target`, which is likely involved in the failure >> that resulted in the emergency target being started. > > I guess that the ssh maintainer could be coaxed into including an > sshd-emergency.service (maybe even socket activated for simplicity, > possible with privilege separation disabled to heighten the chance of > the service being successful) which systemd could use in this case. I > do understand that doing this with the default sshd.service unit would > be a challenge. I don't think such a service needs to be part of ssh (or systemd for that matter), it might actually be better if that was shipped by a separate package, which can be installed on demand for cases likes your (and is ideally maintained by users of such functionality). Such a package could try to bring up the network by itself, by first trying to directly run NM , ifup or even attempting a simple dhclient. Directly, meaning not using the .service units which might have dependencies which might not be satisfied by emergency.target/rescue.target. Then it could try to start an SSH server (with possibly a minimal config). It could even try different implementations, like openssh, dropbear etc. Again, I think this is not something which necessarily has to live in the systemd package. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pkg-systemd-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
