When using sudo with the default ubuntu user inside my 19.04 container, I don’t get asked for a password or other authentication. Is this normal?
If yes, does this apply to all sudo members in containers?
if it is the user created by Ubuntu’s installer i believe it does get password-less sudo privileges. you can change it in /etc/sudoers.
That’s what I looked into, but my sudoers file looked ok to me:
Defaults env_reset
Defaults mail_badpass
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"
# User privilege specification
root ALL=(ALL:ALL) ALL
# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL
# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL
Do you yourself use sudo in your containers? I read online that this might not be the intended behavior. It would certainly require some rethinking on my part, i.e. creating extra users without sudo privileges.
i do use sudo, but i know almost nothing about configuring it. i did set up a few specific users (like admin and phil) to be able to use it, all with no password (on my laptop no one else uses).
i have a background system (based on screen) that i can stuff input into. i usually start one background shell and run “sudo -i” on it. i name it “root” (i just do “bg new root sudo -i” to create it from user phil). then i can input root commands into it when i need to (such as by doing “bg in root mount /{dev,mnt}/sdb4” … with quotes around the command if i need to give it redirects and other characters the shell plays with) sudo makes all this possible for root.
i have managed to configure sude to let me use it without a password from examples i found, and then just left it alone. it has far more sophisticated policy capability than i would ever need.
i used this to let user admin access sudo w/o needing a password:
%admin ALL=(ALL) NOPASSWD:ALL
i have no understanding of this syntax and do not plan to spend the time to learn it.
I’d love to have some input from the developers. I commented out the sudo group in /etc/sudoers:
#%sudo ALL=(ALL:ALL) ALL
yet $ubuntu: sudo <command> still works after container reboot, even though ubuntu is not member of any group remaining there. Enforcing what should be defaults via Defaults authenticate and PASSWD has no effect either. So I feel like this config is actually being ignored.
Update:
Someone in IRC pointed me to /etc/sudoers.d/90-cloud-init-users and indeed that file contains:
ubuntu ALL=(ALL) NOPASSWD:ALL
However, I never included to in /etc/sudoers, so I’m surprised it has any effect (it does).
Now I’m running into this issue (progress at least): https://github.com/lxc/lxd/issues/3218
Should I run script /dev/null on login, or should I maybe add to ~/.bashrc the alias sudo='/usr/bin/sudo -S'? Any thoughts? Presuming the sudoers behavior is enforced, the latter shouldn’t be a security risk, right?
do you have a
#includedir /etc/sudoers.d
line? it will look like a comment but it really isn’t. i have one and a bunch of files in it that get included
for the pty issue i’d use screen (may need to install it) or script /dev/null.
1 Like
You can create a LXD system container with Ubuntu in the two following ways:
-
Using the ubuntu: repository,
lxc launch ubuntu:18.04 mycontainer1 -
Using the images: repository,
lxc launch images:ubuntu/18.04 mycontainer2
In the first case, you get a container image with nice and handy usability features (including the /etc/sudoers.d/90-cloud-init-users configuration file).
In the second case, you do not get such extra configurations. There is no /etc/sudoers.d/90-cloud-init-users in mycontainer2.
But if you can sudo to root as an unprivileged user (well, not any user, just ubuntu), is that really an issue? In other words, should we be running software in a LXD container as ubuntu?
1 Like
hmmm. is there a way to avoid cloud-init entirely? actually, i should be asking how to launch a container with lxd’s nicer lxc command using one of my own existing local “images” (it’s a file tree that i rsync to a subdirectory where i have been using chroot).
For cloud-init to work in a container image, there is need to specially configure the container image to use cloud-init. It requires a bit of effort to make it work, therefore I highly doubt that your container images have enabled accidentally cloud-init. I suppose you have not even installed anyway the cloud-init package in the container, right?
i’m still using chroot and the “images” i use there, which i want to use in containers, do not have cloud-init installed.