Bug#914788: Please don't enable getty services for tty devices that don't exist
On Wed, Jan 30, 2019 at 08:48:34PM +, Dmitry Bogatov wrote:
> > > What is so bad about cluttering environment of daemon?
> >
> > Normally you'd want to avoid passing unnecessary environment variables to
> > daemons. Maybe they'll affect its operation in some way; maybe they'll
> > affect a child process of the daemon that inherits them. It's relying on
> > undefined behaviour.
>
> I do not buy this argument. For ages we started daemons with
> /etc/init.d/{foo} scripts from root shell (and even with sudo), with all
> kind of environment variables, including rather nasty ones, like GREP or
> LESS, and we are still fine.
No we're not. :) Leaking shell envvars (stuff like LC_* and LD_* especially)
into daemon environments is one of the reasons initscripts are a bad idea.
Daemons should be called with a minimal required set of environment
variables.
> But probably executing services with `env -0' is good idea, thank you.
'env -0' will just modify the regular output of env(1), and will have no
effect if you use env to call a program; are you sure that's what you meant?
> > > > (But then /etc/default/foo would have to take precedence over
> > > > sv/foo/conf,
> > > > because the /etc/default/foo variables would be lost during the exec
> > > > since
> > > > we want to avoid exporting them.)
> > >
> > > This too. I want daemontools-style take precedence over sysvinit style.
> >
> > FWIW, I think the whole thing is creeping featurism,
>
> One extra source of variables, implemented with 3 lines of shell? Well,
> your definition of 'featurism' is much stricter then mine.
I meant the entire shebang of having a funky shellscript as an interpreter
for 'run' scripts just so we can avoid 3 lines of shell code in each to set
environment variables is creeping featurism. The idea is original and
certainly has hack value; but I think the benefits don't warrant the added
complexity/abstraction.
However, since using it is entirely optional, it's probably not worth
arguing over; I write most of my run scripts in zsh anyway, so I won't even
be tempted to use the new interpreter.
> > > And what if there were no tty on installation time, and after that they
> > > appeared? (No idea, why, never dealt with devices without tty.)
> >
> > That's a pathological hypothetical case; I'd say we wait until it happens,
> > and then deal with it. (You might also ask: what about hypothetical systems
> > where /dev/tty* devices keep disappearing and reappearing in a rhythm that
> > always prevents getty from starting?)
>
> Okay. I buy it. I will unconditionally include this code:
>
> if ! test -c /dev/@TTY@ ; then
> rm /etc/service/getty-@TTY@
> exit 0
> fi
>
> and upload to experimental. Should there be no report of that
> pathological case, I will merge these changes into unstable after
> Buster. Will it do for you?
Most of the time, yes, thank you. (It won't work when the service directory
isn't /etc/service, but that's rare.)
András
--
"Meow" ...splat... "Aarf" ...splat... (raining cats and dogs)
Bug#914788: Please don't enable getty services for tty devices that don't exist
[2019-01-27 18:56] Andras Korn
> > Complicated. And depends on $0 trickery. We, at sysvinit team, had
> > problems with $0 trickery.
>
> How is this trickery? We're just obtaining the name of the script being
> executed, and its path.
Relying on $0 makes me uneasy. Because one day I may want to re-use this
code, but feed it another $0. No, it is not theoretical issue.
> > What is so bad about cluttering environment of daemon?
>
> Normally you'd want to avoid passing unnecessary environment variables to
> daemons. Maybe they'll affect its operation in some way; maybe they'll
> affect a child process of the daemon that inherits them. It's relying on
> undefined behaviour.
I do not buy this argument. For ages we started daemons with
/etc/init.d/{foo} scripts from root shell (and even with sudo), with all
kind of environment variables, including rather nasty ones, like GREP or
LESS, and we are still fine.
But probably executing services with `env -0' is good idea, thank you.
> > > (But then /etc/default/foo would have to take precedence over sv/foo/conf,
> > > because the /etc/default/foo variables would be lost during the exec since
> > > we want to avoid exporting them.)
> >
> > This too. I want daemontools-style take precedence over sysvinit style.
>
> FWIW, I think the whole thing is creeping featurism,
One extra source of variables, implemented with 3 lines of shell? Well,
your definition of 'featurism' is much stricter then mine.
> but if you think you must do it, I'd prefer it being done sensibly --
> i.e. not depending on undefined behaviour, not leaking environment
> variables. I think this is a stronger argument than personal
> preference (yours or mine).
Sure. But see above.
> > And what if there were no tty on installation time, and after that they
> > appeared? (No idea, why, never dealt with devices without tty.)
>
> That's a pathological hypothetical case; I'd say we wait until it happens,
> and then deal with it. (You might also ask: what about hypothetical systems
> where /dev/tty* devices keep disappearing and reappearing in a rhythm that
> always prevents getty from starting?)
Okay. I buy it. I will unconditionally include this code:
if ! test -c /dev/@TTY@ ; then
rm /etc/service/getty-@TTY@
exit 0
fi
and upload to experimental. Should there be no report of that
pathological case, I will merge these changes into unstable after
Buster. Will it do for you?
--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--
Bug#914788: Please don't enable getty services for tty devices that don't exist
On Sat, Jan 26, 2019 at 10:17:05AM +, Dmitry Bogatov wrote:
Hi,
> > I believe instead of
> >
> > rm /etc/service/getty-@TTY@
> >
> > you should do
> >
> > rm "$(pwd)"
> >
> > because then it won't matter what the service is called and where the
> > runsvdir root is (/etc/service or somewhere else).
> I find it unsafe. Explicit is better implicit.
Except when it doesn't work, because the service directory is somewhere
else... But whatever.
> > While invoke-run, as an interpreter, is an original idea, I'd make it a
> > scriptlet a run script can source via ". /lib/runit/invoke-run". Then it
> > wouldn't be necessary to export all variables the configuration sets and
> > thereby clutter the environment of the daemon.
> >
> > The envdir bit could be handled by a construct like
> >
> > if [ -z "$1" ]; then
> > SVDIR="$(dirname $(readlink -f "$0")"
> > if [ -e "$SVDIR/conf" ]; then
> > exec chpst -e "$SVDIR/conf" -- "$0" "envdir-done"
> > fi
>
> Complicated. And depends on $0 trickery. We, at sysvinit team, had
> problems with $0 trickery.
How is this trickery? We're just obtaining the name of the script being
executed, and its path.
> What is so bad about cluttering environment of daemon?
Normally you'd want to avoid passing unnecessary environment variables to
daemons. Maybe they'll affect its operation in some way; maybe they'll
affect a child process of the daemon that inherits them. It's relying on
undefined behaviour.
> > (But then /etc/default/foo would have to take precedence over sv/foo/conf,
> > because the /etc/default/foo variables would be lost during the exec since
> > we want to avoid exporting them.)
>
> This too. I want daemontools-style take precedence over sysvinit style.
FWIW, I think the whole thing is creeping featurism, but if you think you
must do it, I'd prefer it being done sensibly -- i.e. not depending on
undefined behaviour, not leaking environment variables. I think this is a
stronger argument than personal preference (yours or mine).
> > > Please,
> > >
> > > * build it (it will build runit-2.1.2-22, sorry for version havoc)
> > > * install bin:runit
> > > * install bin:getty-run
> > > * write "yes" into /etc/getty-tty1/conf/GIVE_UP_ON_MISSING_TTY file
> >
> > While this would work, it doesn't improve my situation: you're making me
> > jump through hoops to get sensible behaviour. Creating these files isn't
> > less effort than deleting the getty services on installation, so it just
> > adds complexity and abstraction with no real benefit.
>
> Not exactly. You mentioned that option to pre-seed debconf would help
> you.
Yes; I already preseed debconf with much other stuff. Adding one more
preseed response doesn't add appreciable complexity.
> I provide you with way to pre-provision system -- create
> /etc/default/getty-tty{1..6} before installing runit.
But this is a different mechanism than debconf. Like I said, it would work,
but it's not easier or more comfortable than removing the /service/getty*
symlinks after runit install. It adds complexity to the package without
improving the use-case it is aimed at.
> > I still think the postinst modification I suggested (not installing
> > getty services for non-existing tty devices) would be the cleanest
> > solution.
>
> And what if there were no tty on installation time, and after that they
> appeared? (No idea, why, never dealt with devices without tty.)
That's a pathological hypothetical case; I'd say we wait until it happens,
and then deal with it. (You might also ask: what about hypothetical systems
where /dev/tty* devices keep disappearing and reappearing in a rhythm that
always prevents getty from starting?)
If you're so worried about providing a way to log in even in pathological
cases, you could start a getty on, say, tty7 from /etc/runit/1. (I have at
least one system where I do that.)
> As you can understand, I am wary about defaulting on behavior, that can
> leave user without means to login.
I understand and approve in general, but I think in this case you're taking
it too far, to cover a corner case that doesn't exist.
András
--
Quantum Mechanics: The dreams stuff is made of.
Bug#914788: Please don't enable getty services for tty devices that don't exist
[2019-01-25 10:34] Andras Korn
> I believe instead of
>
> rm /etc/service/getty-@TTY@
>
> you should do
>
> rm "$(pwd)"
>
> because then it won't matter what the service is called and where the
> runsvdir root is (/etc/service or somewhere else).
I find it unsafe. Explicit is better implicit.
> Also, this seems redundant:
>
> #!/usr/bin/env /lib/runit/invoke-run
>
> why not just "#!/lib/runit/invoke-run"?
Because kFreeBSD kernel requires script interpreter to be compiled.
Portability.
> While invoke-run, as an interpreter, is an original idea, I'd make it a
> scriptlet a run script can source via ". /lib/runit/invoke-run". Then it
> wouldn't be necessary to export all variables the configuration sets and
> thereby clutter the environment of the daemon.
>
> The envdir bit could be handled by a construct like
>
> if [ -z "$1" ]; then
> SVDIR="$(dirname $(readlink -f "$0")"
> if [ -e "$SVDIR/conf" ]; then
> exec chpst -e "$SVDIR/conf" -- "$0" "envdir-done"
> fi
Complicated. And depends on $0 trickery. We, at sysvinit team, had
problems with $0 trickery.
What is so bad about cluttering environment of daemon?
> (But then /etc/default/foo would have to take precedence over sv/foo/conf,
> because the /etc/default/foo variables would be lost during the exec since
> we want to avoid exporting them.)
This too. I want daemontools-style take precedence over sysvinit style.
> > Please,
> >
> > * build it (it will build runit-2.1.2-22, sorry for version havoc)
> > * install bin:runit
> > * install bin:getty-run
> > * write "yes" into /etc/getty-tty1/conf/GIVE_UP_ON_MISSING_TTY file
>
> While this would work, it doesn't improve my situation: you're making me
> jump through hoops to get sensible behaviour. Creating these files isn't
> less effort than deleting the getty services on installation, so it just
> adds complexity and abstraction with no real benefit.
Not exactly. You mentioned that option to pre-seed debconf would help
you. I provide you with way to pre-provision system -- create
/etc/default/getty-tty{1..6} before installing runit.
After installing getty-run, you would get behaviour you want. Or I
missed the point?
> I still think the postinst modification I suggested (not installing
> getty services for non-existing tty devices) would be the cleanest
> solution.
And what if there were no tty on installation time, and after that they
appeared? (No idea, why, never dealt with devices without tty.)
As you can understand, I am wary about defaulting on behavior, that can
leave user without means to login.
--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--
Bug#914788: Please don't enable getty services for tty devices that don't exist
On Tue, Jan 22, 2019 at 07:16:43PM +, Dmitry Bogatov wrote: Hi, > > (Alternatively, the getty run scripts could start with something like this: > > > > [ -c /dev/ttyX ] || rm /etc/service/getty-ttyX > > > > and /etc/runit/1 could re-create these symlinks, just to be absolutely sure. > > > > I don't like this approach; there is too much going on automatically.) > > I believe I found quite decent solution. Take a look at `bugfix/914788' > branch. Thanks for looking into this! I believe instead of rm /etc/service/getty-@TTY@ you should do rm "$(pwd)" because then it won't matter what the service is called and where the runsvdir root is (/etc/service or somewhere else). Also, this seems redundant: #!/usr/bin/env /lib/runit/invoke-run why not just "#!/lib/runit/invoke-run"? While invoke-run, as an interpreter, is an original idea, I'd make it a scriptlet a run script can source via ". /lib/runit/invoke-run". Then it wouldn't be necessary to export all variables the configuration sets and thereby clutter the environment of the daemon. The envdir bit could be handled by a construct like if [ -z "$1" ]; then SVDIR="$(dirname $(readlink -f "$0")" if [ -e "$SVDIR/conf" ]; then exec chpst -e "$SVDIR/conf" -- "$0" "envdir-done" fi (But then /etc/default/foo would have to take precedence over sv/foo/conf, because the /etc/default/foo variables would be lost during the exec since we want to avoid exporting them.) > Please, > > * build it (it will build runit-2.1.2-22, sorry for version havoc) > * install bin:runit > * install bin:getty-run > * write "yes" into /etc/getty-tty1/conf/GIVE_UP_ON_MISSING_TTY file While this would work, it doesn't improve my situation: you're making me jump through hoops to get sensible behaviour. Creating these files isn't less effort than deleting the getty services on installation, so it just adds complexity and abstraction with no real benefit. I still think the postinst modification I suggested (not installing getty services for non-existing tty devices) would be the cleanest solution. András -- No pixels were harmed in the creation of this program.
Bug#914788: Please don't enable getty services for tty devices that don't exist
[2019-01-18 20:27] Andras Korn
> sorry, didn't look at bug mail for a while.
>
> > > However, whenever the getty-run package is installed in a vserver, I have
> > > to
> > > manually remove the /service/getty-tty* symlinks.
> > >
> > > Can you please modify the postinst script so it only installs getty
> > > services
> > > for /dev/tty* devices that are actually there?
> >
> > I do not like maintainer scripts. They are pain to get right. I can
> > propose you to pre-provision your servers with
> > `/etc/sv/getty{1-6}-run/down' file. See runsv(8).
>
> That would still leave the runsv processes around and clutter the output of
> "sv status /service/*".
>
> The following postinst snippet should work:
>
> export NAME='getty-tty1'
> if [ -c /dev/tty1 ]; then
> export ENABLE='yes'
> else
> export ENABLE='no'
> fi
>
> # Unlike postrm, I can be sure, that runit-helper is present on
> # postinst.
> /lib/runit-helper/runit-helper postinst "$@"
>
> ... and so on for the other ttys. (A lesser man would have used a for loop. :)
>
> (Alternatively, the getty run scripts could start with something like this:
>
> [ -c /dev/ttyX ] || rm /etc/service/getty-ttyX
>
> and /etc/runit/1 could re-create these symlinks, just to be absolutely sure.
>
> I don't like this approach; there is too much going on automatically.)
>
> Or, you could add a debconf question with low priority, defaulting to "yes",
> on whether to add the getty service symlinks. I could pre-seed debconf in
> vservers with "no".
I believe I found quite decent solution. Take a look at `bugfix/914788'
branch.
Please,
* build it (it will build runit-2.1.2-22, sorry for version havoc)
* install bin:runit
* install bin:getty-run
* write "yes" into /etc/getty-tty1/conf/GIVE_UP_ON_MISSING_TTY file
* did it help?
--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--
Bug#914788: Please don't enable getty services for tty devices that don't exist
On Wed, Nov 28, 2018 at 06:47:59PM +, Dmitry Bogatov wrote:
Hi,
sorry, didn't look at bug mail for a while.
> > However, whenever the getty-run package is installed in a vserver, I have to
> > manually remove the /service/getty-tty* symlinks.
> >
> > Can you please modify the postinst script so it only installs getty services
> > for /dev/tty* devices that are actually there?
>
> I do not like maintainer scripts. They are pain to get right. I can
> propose you to pre-provision your servers with
> `/etc/sv/getty{1-6}-run/down' file. See runsv(8).
That would still leave the runsv processes around and clutter the output of
"sv status /service/*".
The following postinst snippet should work:
export NAME='getty-tty1'
if [ -c /dev/tty1 ]; then
export ENABLE='yes'
else
export ENABLE='no'
fi
# Unlike postrm, I can be sure, that runit-helper is present on
# postinst.
/lib/runit-helper/runit-helper postinst "$@"
... and so on for the other ttys. (A lesser man would have used a for loop. :)
(Alternatively, the getty run scripts could start with something like this:
[ -c /dev/ttyX ] || rm /etc/service/getty-ttyX
and /etc/runit/1 could re-create these symlinks, just to be absolutely sure.
I don't like this approach; there is too much going on automatically.)
Or, you could add a debconf question with low priority, defaulting to "yes",
on whether to add the getty service symlinks. I could pre-seed debconf in
vservers with "no".
> > Or can we come up with a way to help people avoid shooting themselves in the
> > foot while not requiring me to install getty-run in vservers? For example,
> > runit-init could depend on "getty-run | some-way-to-log-in-interactively",
> > and "some-way-to-log-in-interactively" could be provided by an empty
> > "runit-no-getty" package as well as an "ssh-run" package that sets up a
> > runit service for ssh.
>
> If it would help you, I can add dependency on 'getty-run | access-run'.
> You are free to provide `access-run' in whatever way you like.
That would work for me if you also build a "runit-no-getty" or similar
(empty) package that provides "access-run". It should be in Debian; we
shouldn't force every container user to build their own fake empty
"access-run" package.
> I am fine with `bin:unsafe-no-tty-run' package too, but not now. I do not
> want to get stuck in NEW before freeze.
Sure, it can wait until the freeze starts. (I almost always use sid anyway.)
Thanks!
András
--
What is life but a sexually transmitted disease with a 100% mortality rate?
Bug#914788: Please don't enable getty services for tty devices that don't exist
[2018-11-27 11:14] Andras Korn
> Ideally, I wouldn't even have to install the getty-run package, but I
> understand it's there to help avoid people shooting themselves in the
> foot by installing runit and then not having any way to log in.
True. I too do not like hard dependency, but Debian users expect things
to work out-of-box.
> However, whenever the getty-run package is installed in a vserver, I have to
> manually remove the /service/getty-tty* symlinks.
>
> Can you please modify the postinst script so it only installs getty services
> for /dev/tty* devices that are actually there?
I do not like maintainer scripts. They are pain to get right. I can
propose you to pre-provision your servers with
`/etc/sv/getty{1-6}-run/down' file. See runsv(8).
> Or can we come up with a way to help people avoid shooting themselves in the
> foot while not requiring me to install getty-run in vservers? For example,
> runit-init could depend on "getty-run | some-way-to-log-in-interactively",
> and "some-way-to-log-in-interactively" could be provided by an empty
> "runit-no-getty" package as well as an "ssh-run" package that sets up a
> runit service for ssh.
If it would help you, I can add dependency on 'getty-run | access-run'.
You are free to provide `access-run' in whatever way you like.
I am fine with `bin:unsafe-no-tty-run' package too, but not now. I do not
want to get stuck in NEW before freeze.
Bug#914788: Please don't enable getty services for tty devices that don't exist
Package: getty-run Version: 2.1.2-18 Severity: wishlist Hi, I use runit as init extensively in linux-vserver guests which don't have console devices and thus can't run getty. Ideally, I wouldn't even have to install the getty-run package, but I understand it's there to help avoid people shooting themselves in the foot by installing runit and then not having any way to log in. However, whenever the getty-run package is installed in a vserver, I have to manually remove the /service/getty-tty* symlinks. Can you please modify the postinst script so it only installs getty services for /dev/tty* devices that are actually there? Or can we come up with a way to help people avoid shooting themselves in the foot while not requiring me to install getty-run in vservers? For example, runit-init could depend on "getty-run | some-way-to-log-in-interactively", and "some-way-to-log-in-interactively" could be provided by an empty "runit-no-getty" package as well as an "ssh-run" package that sets up a runit service for ssh. András -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (350, 'unstable'), (350, 'stable'), (98, 'bionic'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Versions of packages getty-run depends on: ii runit 2.1.2-18 ii runit-helper 2.7.3 Versions of packages getty-run recommends: ii fgetty 0.7-3 -- Sure, drinking kills brain cells, but only the weak ones.
