reopen 1063905
severity 1063905 wishlist
retitle 1063905 mksh: add /usr/bin/mksh{,-static} to /etc/shells
tags 1063905 + pending
found 1063905 59c-23
# well /usr/bin/mksh, /usr/bin/mksh-static is not, see below
notfound 1063905 59c-22
thanks
Russ Allbery dixit:
>After some research with git blame
On 2024-02-15 16:30:25 -0800, Russ Allbery wrote:
> I was only able to find this discussion of why pkexec checks $SHELL, and
> it doesn't support my assumption that it was an intentional security
> measure, so I may well be wrong in that part of my analysis. Apologies
> for that; I clearly should
On 2024-02-15 16:17:58 -0800, Russ Allbery wrote:
> Vincent Lefevre writes:
> > On 2024-02-15 14:14:46 -0800, Russ Allbery wrote:
>
> >> and pkexec is essentially a type of sudo and should be unavailable to
> >> anyone who is using a restricted shell.
>
> > The pkexec source doesn't say that the
Russ Allbery writes:
> Thorsten Glaser writes:
>> Right… and why does pkexec check against /etc/shells?
> pkexec checks against /etc/shells because this is the traditional way to
> determine whether the user is in a restricted shell, and pkexec is
> essentially a type of sudo and should be unav
Russ Allbery writes:
> That definitely should not be the case and any restricted shell that adds
> itself to /etc/shells is buggy. See chsh(1):
> The only restriction placed on the login shell is that the command
> name must be listed in /etc/shells, unless the invoker is the
> supe
Vincent Lefevre writes:
> On 2024-02-15 14:14:46 -0800, Russ Allbery wrote:
>> and pkexec is essentially a type of sudo and should be unavailable to
>> anyone who is using a restricted shell.
> The pkexec source doesn't say that the goal is to check whether
> the user is in a restricted shell.
On 2024-02-15 14:14:46 -0800, Russ Allbery wrote:
> Thorsten Glaser writes:
>
> > Right… and why does pkexec check against /etc/shells?
>
> pkexec checks against /etc/shells because this is the traditional way to
> determine whether the user is in a restricted shell,
Could you explain? This see
On Thu, Feb 15, 2024 at 10:34:32PM +, Thorsten Glaser wrote:
> Russ Allbery dixit:
>
> >Thorsten Glaser writes:
> >
> >> Right… and why does pkexec check against /etc/shells?
> >
> >pkexec checks against /etc/shells because this is the traditional way to
> >determine whether the user is in a
Russ Allbery dixit:
>Thorsten Glaser writes:
>
>> Right… and why does pkexec check against /etc/shells?
>
>pkexec checks against /etc/shells because this is the traditional way to
>determine whether the user is in a restricted shell, and pkexec is
>essentially a type of sudo and should be unavail
Thorsten Glaser writes:
> Right… and why does pkexec check against /etc/shells?
pkexec checks against /etc/shells because this is the traditional way to
determine whether the user is in a restricted shell, and pkexec is
essentially a type of sudo and should be unavailable to anyone who is
using
Russ Allbery dixit:
>It does check whether $SHELL is found in /etc/shells. So your question
>about what is setting the $SHELL variable is a good one, although I think
>I would still argue that it's not the most effective way to solve the
>issue.
Right… and why does pkexec check against /etc/shel
On 2024-02-15 17:18:43 +, Thorsten Glaser wrote:
> Russ Allbery dixit:
>
> >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
>
> What sets $SHELL for the reporter’s case? Fix that instead.
$SHE
Thorsten Glaser writes:
> Dixi quod…
>> Russ Allbery dixit:
>>> My guess is that pkexec is calling realpath to canonicalize the path
>>> before checking for it in /etc/shells, although I have not confirmed
>>> this.
>> Now that would be weird and should be fixed…
> Another question that probabl
Dixi quod…
>Russ Allbery dixit:
>
>>> What sets $SHELL for the reporter’s case? Fix that instead. login(1)
>>> sets it to the path from passwd(5), which hopefully is from shells(5).
>>
>>My guess is that pkexec is calling realpath to canonicalize the path
>>before checking for it in /etc/shells,
Russ Allbery dixit:
>> What sets $SHELL for the reporter’s case? Fix that instead. login(1)
>> sets it to the path from passwd(5), which hopefully is from shells(5).
>
>My guess is that pkexec is calling realpath to canonicalize the path
>before checking for it in /etc/shells, although I have not
Le Thu, Feb 15, 2024 at 05:18:43PM +, Thorsten Glaser a écrit :
> Russ Allbery dixit:
>
> >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
>
> What sets $SHELL for the reporter’s case? Fix that
Thorsten Glaser writes:
> Russ Allbery dixit:
>> 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
> What sets $SHELL for the reporter’s case? Fix that instead. login(1)
> sets it to the path from
Russ Allbery dixit:
>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
What sets $SHELL for the reporter’s case? Fix that instead.
login(1) sets it to the path from passwd(5), which hopefully
is from s
On 2024-02-15 09:00:57 -0800, Russ Allbery wrote:
> 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 2024-02-15 16:59:28 +, Holger Levsen wrote:
> On Thu, Feb 15, 2024 at 10:08:11AM +0100, Vincent Lefevre wrote:
> > Not for mksh.
>
> so the subject should be "mksh is broken with usrmerge"?
No, because my bug report about mksh was closed because it is
not regarded as a bug in mksh.
--
V
Vincent Lefevre 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 valu
On Thu, Feb 15, 2024 at 10:08:11AM +0100, Vincent Lefevre wrote:
> Not for mksh.
so the subject should be "mksh is broken with usrmerge"?
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1
On 2024-02-15 09:39:51 +0100, Marc Haber wrote:
> On Thu, 15 Feb 2024 00:05:36 +0100, Vincent Lefevre
> wrote:
> >This is invalid. See
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817168
>
> That doesnt answer the question asked, it is a bug from 2016 that was
> fixed since then, an
On 2024-02-14 17:16:23 -0800, Russ Allbery wrote:
> I have literally no idea what you're talking about. It would be really
> helpful if you would describe what program rejected your setting and what
> you expected to happen instead.
Quoting https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817168
On Thu, 15 Feb 2024 00:05:36 +0100, Vincent Lefevre
wrote:
>This is invalid. See
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817168
That doesnt answer the question asked, it is a bug from 2016 that was
fixed since then, and I am one of those who fails to see the
connection between the
Vincent Lefevre writes:
> On 2024-02-14 10:41:44 -0800, Russ Allbery wrote:
>> I'm sorry, this is probably a really obvious question, but could you
>> explain the connection between the subject of your mail message and the
>> body of your mail message? I can't see any relationship, so I guess I
On 2024-02-14 10:41:44 -0800, Russ Allbery wrote:
> Vincent Lefevre writes:
>
> > POSIX says:
>
> > SHELL This variable shall represent a pathname of the user's
> > preferred command language interpreter. If this interpreter
> > does not conform to the Shell Command Langu
On 2024-02-14 19:46:58 +0100, Ansgar 🙀 wrote:
> Hi Vincent,
>
> On Wed, 2024-02-14 at 18:20 +0100, Vincent Lefevre wrote:
> > POSIX says:
> >
> > SHELL This variable shall represent a pathname of the user's
> > preferred command language interpreter. If this interpreter
> >
Hi Vincent,
On Wed, 2024-02-14 at 18:20 +0100, Vincent Lefevre wrote:
> POSIX says:
>
> SHELL This variable shall represent a pathname of the user's
> preferred command language interpreter. If this interpreter
> does not conform to the Shell Command Language in XCU
>
Vincent Lefevre writes:
> POSIX says:
> SHELL This variable shall represent a pathname of the user's
> preferred command language interpreter. If this interpreter
> does not conform to the Shell Command Language in XCU
> Chapter 2 (on page 2345), utilities may b
POSIX says:
SHELL This variable shall represent a pathname of the user's
preferred command language interpreter. If this interpreter
does not conform to the Shell Command Language in XCU
Chapter 2 (on page 2345), utilities may behave differently
from tho
31 matches
Mail list logo
