Frans Pop wrote:
>> For most use cases, this is clearly entirely the correct behaviour. In
>> those rare cases where someone really, really, wants to have an empty
>> password for an automatically created user, it would be nice if
>> user-setup would allow this directly, rather than requiring workarounds
>> such as reset with late_command.
>
> Can you please provide some convincing use-cases for situations where
> someone "really, really" wants to have an empty password?
I "really, really" wanted to do it to ease working with tools that
request graphical sudo authentication for devices that didn't have
keyboards. Yes, this is pointlessly insecure, and yes, there are input
tools that can be used in some cases, but these tend to be fairly
cumbersome.
<...>
> I also don't see why it should be possible to do this for the normal user
> account, but not for the root user account.
That's a fair complaint. I felt that having it only apply for the
normal user was a loose wave towards security, but on reflection have to
agree it's pointless.
> A few comments on the patch itself:
> The description should be "for internal use; can be preseeded" (in line
> with other similar templates). The second line of the description should
> hold a short description of the template (which is now in the comment;
> the comment can then be dropped): "Permit empty password for non-root
> account".
Unless I misunderstand the purpose of the other internal use
templates in user-setup (which is quite possible), I suspect these
issues also need to be addressed for several existing templates. My
apologies for this error.
> Also, the name of the template does not indicate in any way that it's
> restricted to the non-root account.
And as you pointed out above, there's no good reason that if
implemented it shouldn't apply to both. The presented patch is incomplete.
> So to summarize: I don't yet see the necessity of adding this feature,
> especially as creating a passwordless account can trivially be be
> scripted during preseeding, it is insecure, and the implementation is
> inconsistent.
Fair enough. While it makes it easier for me to do what I'm doing,
the fact that it's a rare use case, insecure-by-default, and not too
hard to script is sufficient for me to withdraw the request in the face
of any opposition, rather than fix the patch more generally. If someone
else has a strong enough feeling that it should be present, I'm more
than willing to update the patch to meet the guidelines above.
--
Emmet HIKORY
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
