On Tue, Sep 17, 2013 at 6:10 PM, Kurt Seifried <kurt(a)seifried.org> wrote:
On Tue, Sep 17, 2013 at 8:01 AM, Miloslav Trmač <mitr(a)volny.cz>
wrote:
>
> On Fri, Sep 6, 2013 at 3:04 PM, Matthew Miller <mattdm(a)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