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

[Karel Zak]

On Tue, Oct 28, 2014 at 03:28:32PM +0100, Lennart Poettering wrote:
> 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? 

in agetty and sulogin we already have code to detect possible collisions with
plymouth (implemented by Werner, CC:). The plymounth uses exotic TIOCGLCKTRMIOS
and TIOCSLCKTRMIOS ioctls to lock the tty configuration.

Maybe we can use the same concept, it means lock by TIOCSLCKTRMIOS if we wait 
for user's response.

I have no strong opinion about the lock type (flock or the tty ioctls), but 
I'd like to use the same concept (locks) for all tty components (agetty, 
plymouth and systemd-ask-password) without exceptions.

    Karel

-- 
 Karel Zak  <kzak at redhat.com>
 http://karelzak.blogspot.com