On Tue, Feb 06, 2024 at 05:33:22PM +, Alberto Garcia wrote:
> On Sun, Feb 04, 2024 at 11:05:46PM -0800, Steve Langasek wrote:
> > In fact, none of the t64 binaries currently being uploaded
> > to experimental have the final ABI either, we're just using
> > experimental to clear binary NEW.
> I
Thank you for your rigorous scrutiny regarding the proposed plan.
It was a blindspot on my part that dpkg-buildflags was not a policy mandate,
because by this point I'm quite *used* to using dpkg-buildflags to manage
transitions in the default build flags for the compiler.
What I hadn't taken int
On February 16, 2024 1:11:34 AM UTC, "Marcos Rodrigues de Carvalho (aka oday)"
wrote:
>Package: wnpp
>Severity: wishlist
>Owner: "Marcos Rodrigues de Carvalho (aka oday)"
>X-Debbugs-Cc: debian-devel@lists.debian.org, marcosrcarvalh...@gmail.com
>
>* Package name: asn
> Version :
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
Package: wnpp
Severity: wishlist
Owner: "Marcos Rodrigues de Carvalho (aka oday)"
X-Debbugs-Cc: debian-devel@lists.debian.org, marcosrcarvalh...@gmail.com
* Package name: asn
Version : 0.75.3
Upstream Contact: Adriano nitefood
* URL : https://github.com/nitefood/asn/
*
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
Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ocaml-ma...@lists.debian.org
* Package name: ocaml-crunch
Version : 3.3.1
Upstream Contact: Anil Madhavapeddy
* URL : https://github.com/mirage/ocaml-crunch
* Li
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org
Package Name: python-term-image
Version: v0.7.1
Upstream Author: Toluwaleke Ogundipe
License: MIT
Programming Lang: Python 3
Homepage: https://github.com/AnonymouX47/term-image
Descriptio
Hi,
On Thu, Feb 15, 2024, Steve Langasek wrote:
> > For libfuse2, I think the ABI analysis is broken. The base-to-lfs report
> > supposedly is ok
> > https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/compat_reports/libfuse-dev/base_to_lfs/compat_report.html
> > and then going lfs-to-tim
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
Replying separately to issues unrelated to libselinux, dropping the bug from
cc: and picking a possibly better subject.
First, I want to double check here: the libselinux bug was identified as a
showstopper because removal of the file from disk even briefly breaks dpkg
itself, making recovery impo
32 matches
Mail list logo
