Hi Steve, Since Plymouth is a 'long-running process' wrt the boot and since it is attaching to the console (a shared device), I really don't think it should be making any assumptions -- particularly before requesting a password: it should set a 'secure' terminal environment immediately before prompting. On my test system, over 1500 processes were created between plymouthd starting in the initramfs and my test plymouth client Upstart job running which gives huge scope for a process to tweak the terminal settings after plymouth initially sets them. We could make Upstart perform more intelligent bit-twiddling but there are a _lot_ of options (atleast 47) and Upstart cannot really know which bits it should be twiddling in all scenarios as -- for example -- /dev/console might be attached to a serial line. Upstart cannot make assumptions about the state the console is left in since either something running in the initramfs may have disturbed sane defaults, or as mentioned, there may be no initramfs so a reset generally makes perfect sense I think. The reset it is doing is similar to "stty sane" (which also includes 'ECHO') which gives a 'normal' console setup. Details of when Scott changed the console handling in Upstart (both in Upstream and Ubuntu) are: ------------------------------ revno: 1326 committer: Scott James Remnant branch nick: upstart timestamp: Thu 2011-08-11 13:30:15 -0700 message: * init/main.c: Deal with failure to setup the system console by falling back to /dev/null, so we don't end up without default fds and castrate the process. ------------------------------ We need input from Scott as to the precise retionale for this change since simply undoing it might cause equally bad problems in other parts of the system. I wonder if he implemented it for bug 880049 and just forgot to update that bug? > I don't think the latter part is right, because plymouth is still running at > the end of the job and still owns the console I'm not sure any process owns the console. If we impose policy to state that plymouth does, which plymouth do we mean? The one that runs from the initramfs or the one started as an Upstart job? What about PID 1? What about 'console owner' Upstart jobs? I think the point here is that plymouthd doesn't have awareness of whether it is running in the initramfs or via an Upstart job and Upstart doesn't have an awareness of whether it was started directly or from an initramfs, neither does it know about the existing plymouthd process if that was started from the initramfs. > Also this job has no 'console' line, so the stty command > would have to have its stdin attached to the console somehow... so it's > really not worth trying to deploy a quick fix here. The workaround I outlined wasn't necessarily intended to be included in Ubuntu directly, but was more for users affected by this issue since they could add those two commands relatively easily to restore expected behaviour. I appreciate there is no 'console' stanza, but it doesn't need one - the job runs the plymouth client that asks plymouthd to request a password from the user, and plymouthd is connected to /dev/console. I've checked the latest Plymouth code and it seems there is an attractive compromise for Quantal: plymouth now locks the terminal before resetting it to its chosen defaults. This means that for Quantal (which would include the newer Plymouth) we could change Upstart to only reset the terminal attributes *if the tty in question is not already locked* (we could also add '--force-console-reset' and '--no-console-reset' options to Upstart too for flexibility). This co-operative method for handling console access is in fact how systemd currently attempts to work with Plymouth on Fedora (although it appears the systemd implementation is broken). Whatever approach we take, it might still possible for a job that specifies 'console output' or 'console owner' (including all SysV services) to tweak the attributes underneath Plymouth so the safest approach I feel is for plymouth to also be modified to ensure it requests passwords in a more secure manner. To summarise my thoughts: - For Precise - Fix plymouthd to disable echoing at the point a password is prompted for. and/or: - Potentially revert the Upstart change (once we understand the rationale for change and full implications of reverting). - For Quantal - Fix plymouthd to disable echoing at the point a password is prompted for. - Pull in latest plymouth that locks the terminal attributes. - Stop Upstart resetting the terminal attributes if they are already locked.