Re: [systemd-devel] [PATCH] manager: do not print anything while passwords are being queried
On Tue, Oct 28, 2014 at 03:28:32PM +0100, Lennart Poettering wrote: On Tue, 28.10.14 15:00, Zbigniew Jędrzejewski-Szmek (zbys...@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 (zbys...@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 k...@redhat.com http://karelzak.blogspot.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] manager: do not print anything while passwords are being queried
On Mon, Oct 27, 2014 at 06:37:21PM +0100, Lennart Poettering wrote: On Sun, 26.10.14 05:37, Zbigniew Jędrzejewski-Szmek (zbys...@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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] manager: do not print anything while passwords are being queried
On Tue, 28.10.14 15:00, Zbigniew Jędrzejewski-Szmek (zbys...@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 (zbys...@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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] manager: do not print anything while passwords are being queried
On Sun, 26.10.14 05:37, Zbigniew Jędrzejewski-Szmek (zbys...@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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
