Quoting Michael H. Warfield ([email protected]): > > Why not purely random? I also liked the suggestion of putting the > > password in a file under $lxcpath/$lxcname - though chmod 600 owned > > by the calling user, not root. I prefer not outputting it in > > stdout during create, but am not *strongly* against it. > > I'm actually largely against "purely random" passwords, particularly
Well by purely random I of course meant using a reasonable char set. But I'm lazy and prefer to type (if I have to) 8 random chars to a bunch of boilerplate including mylongcontainername... And realistically, if I'm not using ssh keys, and we have the pwd in a file, i'll be having a script fetch the pwd from the file for me on login. > when we're just trying to defeat a particular attack vector like this, > especially when combined with expiring the password. I'm not sure > there's really anything significant left on the attack tree we need to > worry about (especially with the current state of affairs) and purely > random passwords are a significant PITA. I think xkcd had it nailed > here: > > https://xkcd.com/936/ OTOH for most of the containers I create I'll log in at most once, so memorable passwords are not useful. Also your proposal still had some random chars, so at least with my throwaway approach to containers 2 or 8 random chars makes no difference - I'll have to look it up. But it sounds like we may want to be able to pass a password template, i.e. "lxc_${name}_XXX" (or if on private network then maybe "root") into the template. > I'm open to storing it in a file and, yeah, adding a chown 600 is fine. > Raises and issue though that a number of these templates will only run > as root and have not been adapted for running under a non-priv user. > That's another discussion that I think you and I and others need to > engage in. Sadly some will never work as non-priv user. Including 'ubuntu'. At least until we get an in-kernel workaround enabling user namespaces to create some devices, which debootstrap insists on doing. -serge _______________________________________________ lxc-devel mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-devel
