Vincent Lefevre <vinc...@vinc17.net> writes: > On 2024-02-14 17:16:23 -0800, Russ Allbery wrote:
> Quoting https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817168 > | with usrmerge, some programs - such as pkexec, or LEAP's bitmask > | on top of that- fails to run. Specifically, the error I get is: > | > | The value for the SHELL variable was not found the /etc/shells file >> You mentioned /etc/shells in your previous message, but /etc/shells on my >> system contains both the /usr/bin and the /bin paths, so I'm still at a >> complete loss. > Not for mksh. Okay, thank you. I think I understand now. The problem is: 1. mksh uses custom postinst code to add itself to /etc/shells that does not add the /usr/bin versions of the mksh paths, only the /bin versions. 2. pkexec uses /etc/shells as an authorization mechanism to not allow access from people who use restricted shells, so if it detects your shell as /usr/bin/mksh instead of the (expected by /etc/shells) /bin/mksh path, it will deny access. 3. Something else that I don't yet understand happened that caused pkexec to detect the shell as /usr/bin/mksh instead of /bin/mksh. I'm not sure what this is, but I can guess at a few things that could cause this, so it's not surprising to me that it happened. That pkexec uses /etc/shells in this way is a bit surprising, but I understand the goal. The intent is to keep people who are using restricted shells from accessing pkexec. I'm not sure this is the best way to achieve that security goal, but I can also see the potential for introducing security vulnerabilities in existing systems if we relaxed them now. I think the obvious solution is to ensure that both the /bin and /usr/bin paths for mksh are registered in /etc/shells. In other words, I think we have a missing usrmerge-related transition here that we should just fix. I'm copying Thorsten on this message in case he hasn't noticed this thread, but if I were you I'd just file a bug against mksh asking for the /usr/bin paths to also be added to /etc/shells to match the new behavior of add-shell. Hopefully most shells are using add-shell, and thus won't have this problem, but any other shell package in Debian that is intended to provide a non-restricted shell but is not using add-shell to manipulate /etc/shells will need a similar fix. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
