[systemd-devel] [PATCH] manager: do not print anything while passwords are being queried

[Lennart Poettering]

On Sun, 26.10.14 05:37, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:

> https://bugs.freedesktop.org/show_bug.cgi?id=73942

So in really old systemd versions I had a concept in place of never
printing to the console if there was a controlling process on it. The
kernel's concept of a controlling process we used as a somewhat
natural synchronization on the tty. However, this functionality has
pretty much been lost. 

I am not entirely sure what happened between all the reworks there,
but maybe we should just resurrect that scheme? Suppressing output on
the console if there's a controlling process would not just
automatically avoid mixing password queries with getty login prompts,
but also all other cases where some process wants exclusive ownership
of the tty.

Using the controlling tty for this would be somewhat nice, as all
users of the tty would just work with it. Another idea could be to use
BSD locks on the /dev/console device node. Everybody with access on
the tty could take one of the logs. We would even have R/W locks then,
where the status output would just take a read lock, while things like
gettys and the password stuff would take a full write lock.

Either solution appears nicer to me then explicitly hooking up PID 1
with the ask-password stuff, in particularly, because we really should
look into moving hte ask-password onto kdbus and the kernel keyring,
and we hence shouldn't add cross-links to it now, where we already
know it should probably go away the way it currently is. 

The BSD lock scheme would be pretty much race-free afaics. The
controlling process stuff otoh would be race-ful, probably to the same
level as watching the ask-password stuff.

Anyway, opinions on this?

I am slightly leaning towards the BSD lock solution I must say. In
particular as it is compatible with the story we kinda want to push
people using /dev/ttyS* towards, who really should use BSD locks too,
instead of the awful "LCK.." files...

Lennart

-- 
Lennart Poettering, Red Hat