cannot add new sudo users

[Oliver Grawert]

currently /etc/group is readonly, so when adding a new user to the system and trying to make this user a member of the sudo group will fail. it needs to be researched if the sudo group can be added to the libnss-extrausers setup we have in snappy without any impact. if that is the case we should do the necessary steps in livecd-rootfs to move it over, if this is not the case /etc/group and /etc/gshadow need to be made writable instead.

[Oliver Grawert (ogra)]

to make locking of the group and gshadow files possible the setup needs to be similar to the timezone and hostname setup used in snappy via /etc/writable

[Oliver Grawert (ogra)]

The following works and will not require /etc/group or /etc/gshadow to be writable, this should be added to the documentation.

MYUSER=ogra
echo "$MYUSER ALL=(ALL:ALL) ALL" | sudo tee -a /etc/sudoers.d/90-sudo-users >/dev/null

[Mark Shuttleworth (sabdfl)]

On 13/09/15 15:03, Oliver Grawert wrote:
> The following works and will not require /etc/group or /etc/gshadow to
> be writable, this should be added to the documentation.

That doesn't look like a classy result. If we want people to add sudo
users, then we want a cleaner approach.

Mark

[Oliver Grawert (ogra)]

ok, re-opened :)

[Mark Shuttleworth (sabdfl)]

A better way to think of these cases where the end result is that /etc/
or something else has been configured is:

 * what would a "mediation service" for this look like
 * how would we allocate permissions / capabilities for this

The mediation service could be as complex as the content hub, which
mediates access to content with the help of the apps and the user, or as
simple as "the ability to run add-user". So it might be that we allow
some snaps to add users, that's a permission they ask for, and if they
get it then they can run add-user. In between would be a custom thing we
write which is like a "add-user simplified for snaps".

Mark

[Oliver Grawert (ogra)]

Well, especially in the case of user management we are facing the problem that we cant really ever make the /etc/passwd|group|shadow files writable to keep UID/GID consistency with the filesystem.

if we would make them writable each upgrade would become a very complex three way merge for the writable files (ownership of dirs and files on the readonly images is bound to the UIDs/GIDs, if a user gets dropped or the numbers change for some other reason you would have to revert/manage that in the files or would have to iterate over the whole running filesystem to adjust ownerships ... we have checks in the image build process to make sure the IDs always stay consistent)

sudo seemingly doesnt get along with the move of the sudo group to the nss-extrausers setup and making the group file writable will cause the above mentioned problems.

if we have a "snappy config user-add" or "snappy config admin-add" thingie with a helper service i think using the /etc/sudoers.d mechanism through it isn't the worst approach (alongside the fact that cloud-init does the same today).

IMHO we should consider dropping the sudo group completely once such a helper service exists and simply rely on per package or per user sudoers.d snippets ... the sudo group is great for a generic multiuser setup like we might have on desktop or server, but probably not in the snappy world.

(on a sidenote i think we should get rid of the ubuntu user asap, having a guessable user (with guessable password) on potentially internet facing devices is rather awful, i currently use a script like http://paste.ubuntu.com/12396598/ for my internet facing snappy installs and it would be great if that could shrink down to a simple snappy config call )

[Dustin Kirkland  (kirkland)]

On Mon, Sep 14, 2015 at 4:58 AM, Oliver Grawert <email address hidden> wrote:
> (on a sidenote i think we should get rid of the ubuntu user asap, having
> a guessable user (with guessable password) on potentially internet
> facing devices is rather awful, i currently use a script like
> http://paste.ubuntu.com/12396598/ for my internet facing snappy installs
> and it would be great if that could shrink down to a simple snappy
> config call )

The problem here isn't the guessable username. It's the guessable password.

Keep the 'ubuntu' username. That's always been nice and friendly for
users and good branding for us.

Instead, make those instances "owned", just like we are making the
devices "owned".

And by "owned", simply tie them to a Launchpad (or Github) account.

ssh-import-id supports secure, reliable retrieval and installation of
SSH keys from both Launchpad and Github.

So just provide a nice clean way of saying that "this internet facing
instance/device is owned by $LAUNCHPAD_ID|$GITHUB_ID"

[Mark Shuttleworth (sabdfl)]

We cannot assume that "ubuntu" is an appropriate default username for a
branded device.

Mark

[Oliver Grawert (ogra)]

i really dont want to have an "ubuntu" user active on any of my production servers ... i perfer to use my "ogra" user with a strong password, PW auth disabled in ssh and a key in place, if we ever want to extend into a cloud or server space with snappy, user management must be possible one or the other way (and even more so when we move on with "personal")

[Michael Vogt (mvo)]

This is fixed in 16:

root@localhost:~# snap create-user --force-managed --sudoer <email address hidden>
created user "ogra"