cracklib dicts size (and fedora password policy)

[Miloslav Trmač]

On Tue, Sep 17, 2013 at 6:10 PM, Kurt Seifried <kurt at seifried.org> wrote:
> On Tue, Sep 17, 2013 at 8:01 AM, Miloslav Trmač <mitr at volny.cz> wrote:
>>
>> On Fri, Sep 6, 2013 at 3:04 PM, Matthew Miller <mattdm at fedoraproject.org>
>> wrote:
>> 2) A typical "application separation container" should, IMHO, not even
>> have a password database used for management, let alone a login shell.
>>  (Just launch a shell process and attach it into the container.)  So,
>> in that case, the database should be removed, not made smaller.  Right
>> now that would mean removing all of PAM, which is somewhat problematic
>> (if the application uses PAM to authenticate access to the
>> application.).
>
> Well there's the world we should have, and the world we actually have.
Well, sure.

>> 3) For both virtualization and virt-like containers that accept
>> authentication by "keys or kerberos", wouldn't it make most sense to
>> disable password authentication altogether, then?
>
> See above answer.
>
>> If 1) is false, 2) and 3) suggest to me that this might be best solved
>> by packaging the "password creation/change functionality" as an
>> optional component (encompassing libpwquality+cracklib*+perhaps some
>> parts of PAM), installed by default in @core, that the ultra-small
>> setups could just remove (and if they were missing, creating/changing
>> passwords would have to fail).
>
> How does one log into the image to make changes?

See 2) above - create a process, attach it into the container, then
exec a shell. This requires privileges on the server, but not within
the container.

> not everyone will be able
> to easily manage/modify the JEOS images using tools, so again you just
> excluded a large chunk of people from using them. I think logging into an
> image via SSH is a pretty common feature/requirement and we should continue
> to support it.

Yes, definitely - for the distribution default.  The JEOS case is
already deviating from defaults, by definition.


> I'm not sure having the dictionaries at all really helps, and the people
> using JEOS are (hopfully) a bit more clued in than the average user who pops
> a Linux CD into the laptop to install and see what it's all about =).

Right, but we are not _yet_ in the multi-product world where we can
easily tailor the cloud image for a different user audience to this
extent.
    Mirek