Control: tags -1 moreinfo help
Control: outlook -1 wait for help, close 2022-04-30
thanks
On Sat, Dec 11, 2021 at 12:38:01PM +0100, Oswald Buddenhagen wrote:
> > How would I obtain that debug output?
> >
> add "debug" to the pam_xauth.so line, as is shown in the followup messages
> to this report
tags #687164 - moreinfo
thanks
On Sat, Dec 11, 2021 at 12:38:01PM +0100, Oswald Buddenhagen wrote:
> add "debug" to the pam_xauth.so line, as is shown in the followup messages
> to this report, and as you could have found out yourself by searching for
> "linux pam enable debug output". ;-)
>
> p.
On Sat, Dec 11, 2021 at 09:16:04AM +0100, Marc Haber wrote:
is this still reproducible in current unstable?
no (logs edited for brevity):
=== su
(to root) ossi on pts/13
pam_xauth(su:session): requesting user 1000/100, target user 0/0
pam_xauth(su:session): reading keys from `/home/ossi/.
tags #687164 moreinfo
thanks
Hi,
is this still reproducible in current unstable?
On Mon, Sep 10, 2012 at 02:50:14PM +0200, Oswald Buddenhagen wrote:
> sudo apparently sets the wrong requesting user (which is just the real
> uid of the process, iirc) when calling the pam stack, which breaks at
>
On 2012-09-10 14:50, Oswald Buddenhagen wrote:
> sudo apparently sets the wrong requesting user (which is just the real
> uid of the process, iirc) when calling the pam stack, which breaks at
> least pam_xauth.
I started looking through the code but then realized the problem is
irreconcilable desi
Christian Kastner wrote:
> Background: sudoers(5) says
>
> # Run X applications through sudo; HOME is used to find the
> # .Xauthority file. Note that other programs use HOME to find
> # configuration files and this may lead to privilege escalation!
> Defaults env_keep += "DISPLAY
On 2012-09-10 14:50, Oswald Buddenhagen wrote:
> Package: sudo
> Version: 1.8.5p2-1
> Severity: normal
>
> sudo apparently sets the wrong requesting user (which is just the real
> uid of the process, iirc) when calling the pam stack, which breaks at
> least pam_xauth. compare the debug outputs:
I
Package: sudo
Version: 1.8.5p2-1
Severity: normal
sudo apparently sets the wrong requesting user (which is just the real
uid of the process, iirc) when calling the pam stack, which breaks at
least pam_xauth. compare the debug outputs:
=== su (works) ===
pam_unix(su:session): session opened for us
8 matches
Mail list logo