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

[Lennart Poettering]

On Tue, 28.10.14 15:00, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:

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

Well, so, on the console it is fine if five clients write messages at
the same time (as long as they print full lines at a time). However,
only one client should read fro it at the same time, as otherwise it's
pretty much random which component will actually get the input.

We can use the BSD LOCK_SH vs. LOCK_EX bits for this. LOCK_SH is for
everything which wants to just print a status message, LOCK_EX is for
everything which wants to also read input. The weird bit of course is
that in this case the writers take shared locks and the readers
exclusive locks, even though classic R/W locks are of course the other
way round...

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

One question remains though: which part shall take the LOCK_EX locks?
I figure this should be agetty. 

Karel, can we convince you to take a LOCK_EX BSD file lock on the tty
devices agetty opens? 

Lennart

-- 
Lennart Poettering, Red Hat