Bug#501849: Please permit installation with an empty user password - Debian

This is a discussion on Bug#501849: Please permit installation with an empty user password - Debian ; > 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 ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Bug#501849: Please permit installation with an empty user password

  1. Bug#501849: Please permit installation with an empty user password

    > 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'm not at all convinced we should add this. IMO this adds needless
    complexity and code paths that will seldom be used and probably never
    tested. It also makes it possible to create an inherently insecure
    system, something we've always tried to avoid. And finally the
    documentation of such extremely rarely used options can only confuse
    users.

    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.

    A few comments on the patch itself:
    > +# Allow preseeding whether to permit a blank password for created
    > non-root user
    > +Template: passwd/allow-password-empty
    > +Type: boolean
    > +Default: false
    > +Description: for internal use only


    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".
    Also, the name of the template does not indicate in any way that it's
    restricted to the non-root account.

    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.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEABECAAYFAkjwC2cACgkQgm/Kwh6ICoRIKgCfVDlcwvhFZamI4AuhlZZyLU+/
    //AAnj13CgFpqUnkodMwNoF+rnYUK2PA
    =VaAF
    -----END PGP SIGNATURE-----


  2. Bug#501849: Please permit installation with an empty user password

    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 debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  3. Bug#501849: Please permit installation with an empty user password

    Emmet Hikory writes:

    > 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.


    I believe it is a nice option to be supported, even more that the
    Debian Embedded effort is starting to be integrated on the
    distribution.

    With that in mind, I also believe it is not worth to get it included
    in Lenny and then we should postpone it for after release.

    So to summarise:

    - let it for Lenny+1;
    - fix the description of the templace;
    - add support for root passwordless;

    Do people agree with my POV?

    --
    O T A V I O S A L V A D O R
    ---------------------------------------------
    E-mail: otavio@debian.org UIN: 5906116
    GNU/Linux User: 239058 GPG ID: 49A5F855
    Home Page: http://otavio.ossystems.com.br
    ---------------------------------------------
    "Microsoft sells you Windows ... Linux gives
    you the whole house."



    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

+ Reply to Thread