There is no issue with creating a root password via lxc-attach and passwd in an unprivileged container but very curiously it is not possible to create a password the same way for a privileged container (tried centos 7 and ubuntu cosmic),
The error reads
passwd: System error
passwd: Authentication token manipulation error
From journalctl -f it reports
passwd[7799]: PAM audit_log_acct_message() failed: Operation not permitted
Tried also chroot /srv/lxc/container/rootfs passwd but that is not working for either unprivileged or privileged container.
Now why would setting a password in an unprivileged container work but not in a privileged one and how to remedy, or is it a (nother systemd) bug perhaps?
This sounds similar of an issue also considering the patch - removing NoNewPrivileges=true and adding CAP_AUDIT_WRITE to CapabilityBoundingSet
Tried with lxc.cap.keep = CAP_AUDIT_WRITE but the container would not boot.
Switched kernel to 4.19.6-041906-generic but the issue persists.
with lxc.cap.keep = CAP_AUDIT_WRITE and lxc-start test -F -L /tmp/test.log just nothing happens, no output on the console, the log file is created but empty.
From the host log it appears that the network device gets engaged but that is all (container not booting). Instead there appears this line
new mount options do not match the existing superblock, will be ignored
Used only unprivileged containers thus far and there is no so issue with it, that was prior prior to 3.0.2 and on bionic. LXC been upgraded through the cycles to now 3.0.3.
Now I need a server monitoring app to run a in a privileged container and hence 3.0.2 been indeed the first time that privileged container was tried.
From a user perspective it baffles that it happens with privileged containers but not unprivileged. But suppose that is because of different uid/gid involved?
Unless I am suffering a misconception the root user of the privileged container is the same as on the host (INIT ID - Defaults to: UID(0), GID(0)).
Thus should it not be possible with lxc-console to log into the privileged container with the host’s root credentials? Having tried this it produces however
Nope, privileged containers mean that uid 0 in the container is mapped to uid 0 outside of it.
This doesn’t however relate in any way with credentials as login credentials are purely a userspace concept implemented by the shadow tools and login command.
Can you show the permissions on the containers rootfs files (A simple ls -al will do.).
This seems like a very odd error. The only reasonable explanation seems wrong permissions
or ownership of needed files.
You seem to be using the rootfs of an unprivileged container but with a config without id mappings set up. So what’s happening is perfectly in order:
root@wittgenstein|~
> vim /home/brauner/.local/share/lxc/c1/
[1]+ Stopped nvim /home/brauner/.local/share/lxc/c1/
root@wittgenstein|~
> sudo lxc-start c1 -P /home/brauner/.local/share/lxc/
root@wittgenstein|~
> sudo lxc-attach c1 -P /home/brauner/.local/share/lxc/
root@c1:/# passwd
Enter new UNIX password:
Retype new UNIX password:
passwd: System error
passwd: password unchanged
root@c1:/# ls -al /etc/passwd
-rw-r--r-- 1 100000 100000 1249 Aug 21 07:45 /etc/passwd
In the privileged container settings these are commented out (disabled)
# lxc.idmap = u 0 100000 65536
# lxc.idmap = g 0 100000 65536
Thus I would expect the container being privileged and not unprivileged.
However in the default.conf they are not commented out. And what appears to happen is that lxc-create is applying the settings from the default.conf as unprivileged container and the container specific settings (privileged) cannot be applied anymore.
I am not sure that this logic well documented. I am closing the downstream bug.
@stgraber I think the aramko account is a forum spam account. The text so you never had this working then? is part of an earlier reply of yours in this thread. The way these spam accounts work, is they copy text from earlier replies/posts and submit them again.
This user has two posts here, and in both cases they copy text verbatim from a previous reply in the thread.