Autor: anonym Data: A: The Tails public development discussion list Assumpte: Re: [Tails-dev] Please review (and merge?)
feature/better_power_off_button
20/11/12 19:54, anonym wrote: > 20/11/12 17:48, anonym wrote:
>> * Making the amnesia user password-less (i.e. `passwd -d amnesia`) seems
>> to override Tails Greeter. I can see TG flicker by when X starts, but it
>> proceeds to GNOME before I have the chance to interact with it. Any one
>> has any ideas? [This is the reason I didn't merge this branch into
>> experimental.]
>
> Per ague's suggestion (over IRC) about this being PAM-realated I looked
> into it a bit more. The current configuration has "nullok_secure" for
> "traditional password authentication", which means that empty passwords
> are ok when used on secure tty's. Removing it prevents gdm from skipping
> Tails Greeter and go directly to GNOME, but then X aborts with PAM
> errors when I click "Login" in Tails Greeter. I'm no PAM expert, but
> this seems like a lost cause to me.
An alternative would be to revert commit 7e0de9c ("Make the default user
password-less.") and instead have Tails Greeter make the amnesia user
password-less in case an administrative password isn't set. This would
work as expected, and can easily be simulated by setting a root password
(using rootpw= on the kernel cmdline) and switching out to a console and
running `passwd -d amnesia` right before clicking "Login" in Tails Greeter.
However, if X restarts after the amnesia user's password has been
deleted (so we didn't set an administrative password), we'd be back in
the same situation; Tails Greeter would be skipped, and any options
(e.g. locale) selected in it the previous time wouldn't be selected this
time. OTOH I suppose we assume X restarts won't happen, so it's not a
big issue. Or do we have a "policy" on how Tails Greeter should respond
to X restarts/crashes?
That said, I'd rather have a proper solution, not a workaround, that
builds on keeping commit 7e0de9c. Any one has any ideas or opinions
?
