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

[Zbigniew Jędrzejewski-Szmek]

On Mon, Oct 27, 2014 at 06:37:21PM +0100, Lennart Poettering wrote:
> 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.
I don't get this r/w distinction. In either case access has to
be exclusive.

> 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?
Like it.

> 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...

Zbyszek