Doesn't work if user is managed by Active Directory (contains @ "at" sign) #585
Comments
debarshiray
changed the title
|
From #1022 the actual error seems to be: For others facing this issue, it will be good to know what you get from: |
|
There's a |
|
Hit same issue, we could resolve this in the usermod/useradd and skip passwd -d for the user? |
|
Hate to suggest it but maybe relying on a working |
Good to know. If we can do everything with Could you please show me how the container's |
The thing is that we already require a somewhat modern and functional Shadow (ie., at least 4.9) for enterprise FreeIPA set-ups. Among all the operating systems that Toolbx claims to support (ie., Arch Linux, Fedora, RHEL and Ubuntu), it's only a problem for Ubuntu because only Ubuntu 22.10 has a new enough Shadow. So, I wouldn't worry too much about it. It looks like |
These tests assume that the group and user information on the host operating system can be provided by different plugins for the GNU Name Service Switch (or NSS) functionality of the GNU C Library. eg., on enterprise FreeIPA set-ups. However, it's expected that everything inside the Toolbx container will be provided by /etc/group, /etc/passwd, /etc/shadow, etc.. While /etc/group and /etc/passwd can be read by any user, /etc/shadow can only be read by root. However, it's awkward to use sudo(8) in the test cases involving /etc/shadow, because they ensure that root and $USER don't need passwords to authenticate inside the container, and sudo(8) itself depends on that. If sudo(8) is used, the test suite can behave unexpectedly if Toolbx didn't set up the container correctly. eg., it can get blocked waiting for a password. Hence, 'podman unshare' is used instead to enter the container's initial user namespace, where $USER from the host appears as root. This is sufficient because the test cases only need to read /etc/shadow inside the Toolbx container. Note that 'run --keep-empty-lines' counts the trailing newline on the last line as a separate line. containers#585
|
We did discuss this with @debarshiray today. I strongly advise not to do user modification operations like 32 character limit is due to utmp structure being this limited. Other software did limit itself based on this fact. Linux is in a bit better state, though, because FreeBSD has this limited to 16 characters. |
It's one less invocation of an external command, which is good because spawning a new process is generally expensive. One positive side-effect of this is that on some Active Directory set-ups, the entry point no longer fails with: Error: failed to remove password for user [email protected]: failed to invoke passwd(1) ... because of: # passwd --delete [email protected] passwd: Libuser error at line: 210 - name contains invalid char `@'. This is purely an accident, and isn't meant to be an intential change to support Active Directory. Tools like useradd(8) and usermod(8) from Shadow aren't meant to work with Active Directory users, and, hence, it can still break in other ways. For that, one option is to expose $USER from the host operating system to the Toolbx container through a Varlink interface that can be used by nss-systemd inside the container. containers#585
Yes, let's try to expose However, the road to getting there is messy because of reasons. :) Currently, we are stuck using However, the Even when we can use So, we will still need to maintain the As far as that fallback code is concerned, I do like the idea of replacing the |
It's one less invocation of an external command, which is good because spawning a new process is generally expensive. One positive side-effect of this is that on some Active Directory set-ups, the entry point no longer fails with: Error: failed to remove password for user [email protected]: failed to invoke passwd(1) ... because of: # passwd --delete [email protected] passwd: Libuser error at line: 210 - name contains invalid char `@'. This is purely an accident, and isn't meant to be an intential change to support Active Directory. Tools like useradd(8) and usermod(8) from Shadow aren't meant to work with Active Directory users, and, hence, it can still break in other ways. For that, one option is to expose $USER from the host operating system to the Toolbx container through a Varlink interface that can be used by nss-systemd inside the container. Based on an idea from Si. containers#585
It's one less invocation of an external command, which is good because spawning a new process is generally expensive. One positive side-effect of this is that on some Active Directory set-ups, the entry point no longer fails with: Error: failed to remove password for user [email protected]: failed to invoke passwd(1) ... because of: # passwd --delete [email protected] passwd: Libuser error at line: 210 - name contains invalid char `@'. This is purely an accident, and isn't meant to be an intential change to support Active Directory. Tools like useradd(8) and usermod(8) from Shadow aren't meant to work with Active Directory users, and, hence, it can still break in other ways. For that, one option is to expose $USER from the host operating system to the Toolbx container through a Varlink interface that can be used by nss-systemd inside the container. Based on an idea from Si. containers#585
|
@fallendusk @yrro @woolsgrs Does #1349 work around this problem for you, while we work on the proper solution that @abbra laid out? |
This works, thanks!
FYI with your PR there is no entry for my user in
|
|
Ditto what I found in my testing it just omits the shadow entry |
|
Yes, that sounds correct. If you look at the The root cause of this lies in what So, even when we were using Thanks for testing it out, @yrro and @woolsgrs ! Much appreciated. |
Describe the bug
Toolbox fails to initialize while run as domain/enterprise user. The /run/user/809201000/toolbox/container-initialized file is never created. I manually added this user to /etc/subuid and /etc/subgid. Toolbox works on this VM with non-enterprise login. I can manually run podman to launch the fedora-toolbox container and it also works sans all the toolbox magic.
Steps how to reproduce the behaviour
Try to run toolbox enter with an enterprise user
Expected behaviour
Toolbox should work as it does with a normal linux user.
Actual behaviour
Screenshots
If applicable, add screenshots to help explain your problem.
Output of
toolbox --version(v0.0.90+)toolbox version 0.0.96
Toolbox package info (
rpm -q toolbox)toolbox-0.0.96-1.fc32.x86_64
Output of
podman versionPodman package info (
rpm -q podman)podman-2.1.1-7.fc32.x86_64
Info about your OS
Silverblue 32 using sssd for AD integration
Additional context
The text was updated successfully, but these errors were encountered: