On Tue, 26.11.13 09:53, Colin Guthrie (gm...@colin.guthr.ie) wrote:
> >> I'm proposing a simple goal: XDG_RUNTIME_DIR should always be that
> >> matching the current uid. I can't think of any case where you'd
> >> want it otherwise.
> >
> > That can't work. As the directory only exists when a re
On Tue, 26.11.13 07:19, Martin Pitt (martin.p...@ubuntu.com) wrote:
Heya,
> Lennart Poettering [2013-11-26 5:17 +0100]:
> > That can't work. As the directory only exists when a real login session
> > is around. su/sudo don't get their own login sessins, hence the dir
> > doesn't necessarily exis
On Tue, 2013-11-26 at 09:53 +, Colin Guthrie wrote:
> Colin W's later patch did implement these semantics for the root user's
> XDG_RUNTIME_DIR. It kept it around and didn't tidy it up. Doesn't this
> solve the problem for the root user nicely (which is the primary problem)?
Yes, I run "pkexe
On Tue, Nov 26, 2013 at 02:39:49PM +, Colin Guthrie wrote:
> 'Twas brillig, and Dr. Werner Fink at 26/11/13 14:21 did gyre and gimble:
> > On Tue, Nov 26, 2013 at 10:41:36AM +, Colin Guthrie wrote:
> >> 'Twas brillig, and Martin Pitt at 26/11/13 06:19 did gyre and gimble:
> >>> Hey Lennart,
'Twas brillig, and Dr. Werner Fink at 26/11/13 14:21 did gyre and gimble:
> On Tue, Nov 26, 2013 at 10:41:36AM +, Colin Guthrie wrote:
>> 'Twas brillig, and Martin Pitt at 26/11/13 06:19 did gyre and gimble:
>>> Hey Lennart,
>>>
>>> Lennart Poettering [2013-11-26 5:12 +0100]:
I implemente
On Tue, Nov 26, 2013 at 10:41:36AM +, Colin Guthrie wrote:
> 'Twas brillig, and Martin Pitt at 26/11/13 06:19 did gyre and gimble:
> > Hey Lennart,
> >
> > Lennart Poettering [2013-11-26 5:12 +0100]:
> >> I implemented this now, using a different approach than Martin's
> >> original patch (i.
'Twas brillig, and Martin Pitt at 26/11/13 06:19 did gyre and gimble:
> Hey Lennart,
>
> Lennart Poettering [2013-11-26 5:12 +0100]:
>> I implemented this now, using a different approach than Martin's
>> original patch (i.e. I don't think it is a good idea to involve stat()
>> here, instead let's
'Twas brillig, and Lennart Poettering at 26/11/13 04:17 did gyre and gimble:
> On Wed, 20.11.13 19:19, Colin Walters (walt...@verbum.org) wrote:
>
>>> So yeah, there your mix
>>> and match is broken:
>>
>> I'm proposing a simple goal: XDG_RUNTIME_DIR should always be that
>> matching the current
Hey Lennart,
Lennart Poettering [2013-11-26 5:12 +0100]:
> I implemented this now, using a different approach than Martin's
> original patch (i.e. I don't think it is a good idea to involve stat()
> here, instead let's just let logind pass all information to
> pam_systemd).
Thanks!
Lennart Poet
On Wed, 20.11.13 19:19, Colin Walters (walt...@verbum.org) wrote:
> > So yeah, there your mix
> > and match is broken:
>
> I'm proposing a simple goal: XDG_RUNTIME_DIR should always be that
> matching the current uid. I can't think of any case where you'd
> want it otherwise.
That can't work.
On Thu, 21.11.13 00:36, Lennart Poettering (lenn...@poettering.net) wrote:
> I do like Martin's original patch, since by unsetting XDG_RUNTIME_DIR it
> basically tells apps "Hey, all bets are off, you are fucked", and
> doesn't pretend XDG_RUNTIME_DIR would still work. Because it doesn't.
I imple
'Twas brillig, and Colin Walters at 22/11/13 17:05 did gyre and gimble:
> On Wed, 2013-11-20 at 19:19 -0500, Colin Walters wrote:
>> I care about pkexec.
>
> Note we're now carrying a workaround for this:
>
> https://bugs.freedesktop.org/show_bug.cgi?id=71894
Thanks for that Colin, I'll pick up
On Wed, 2013-11-20 at 19:19 -0500, Colin Walters wrote:
> I care about pkexec.
Note we're now carrying a workaround for this:
https://bugs.freedesktop.org/show_bug.cgi?id=71894
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http:
'Twas brillig, and Colin Walters at 21/11/13 00:32 did gyre and gimble:
> On Thu, 2013-11-21 at 01:20 +0100, Michael Biebl wrote:
>> 2013/11/18 Michael Stapelberg :
>>> This is a rather pressing issue for us (it breaks GDM logins in some
>>> cases), and we’d like to fix it by cherry-picking a patch
2013/11/21 Michael Biebl :
> Hm, yeah, that might be it.
> I guess one would have to ask the bug reporters if they had used su to
> start a root X application (in case they remember) and if the problem
> goes away after a reboot, i.e. /run has been "reset".
Actually, starting a root X application
2013/11/21 Colin Walters :
> On Thu, 2013-11-21 at 01:20 +0100, Michael Biebl wrote:
>> 2013/11/18 Michael Stapelberg :
>> > This is a rather pressing issue for us (it breaks GDM logins in some
>> > cases), and we’d like to fix it by cherry-picking a patch that was
>> > merged upstream.
>>
>> "some
2013/11/21 Colin Walters :
> On Thu, 2013-11-21 at 01:20 +0100, Michael Biebl wrote:
>> 2013/11/18 Michael Stapelberg :
>> > This is a rather pressing issue for us (it breaks GDM logins in some
>> > cases), and we’d like to fix it by cherry-picking a patch that was
>> > merged upstream.
>>
>> "some
On Thu, 2013-11-21 at 01:20 +0100, Michael Biebl wrote:
> 2013/11/18 Michael Stapelberg :
> > This is a rather pressing issue for us (it breaks GDM logins in some
> > cases), and we’d like to fix it by cherry-picking a patch that was
> > merged upstream.
>
> "some cases" is very vague.
See:
https
On Thu, 2013-11-21 at 00:36 +0100, Lennart Poettering wrote:
> On Tue, 19.11.13 13:13, Colin Walters (walt...@verbum.org) wrote:
>
> > Anyways, new tested patch attached. Lennart, any objections?
>
> Yes. Let's not tape over problems and pretend things could work if we
> freely mix and match thi
2013/11/18 Michael Stapelberg :
> This is a rather pressing issue for us (it breaks GDM logins in some
> cases), and we’d like to fix it by cherry-picking a patch that was
> merged upstream.
"some cases" is very vague. Reading through the gdm bug report (or the
one re-assigned to libpam-systemd) i
On Thu, 2013-11-21 at 00:32 +0100, Lennart Poettering wrote:
> On Tue, 19.11.13 10:42, Colin Walters (walt...@verbum.org) wrote:
>
> > My patch though starts to pave the way for having XDG_RUNTIME_DIR
> > consistently point to that of the user's uid
>
> I think this is just bogus. You used "su".
2013/11/21 Lennart Poettering :
> For that, add a new parameter to pam_systemd maybe
> "force-new-session=yes/no" or so which is set in "su -"'s PAM config
> stack, but not in "su"'s PAM config stack (luckily they are stored in
> two separate files).
This is not the case for Debian based distros,
On Tue, 19.11.13 13:13, Colin Walters (walt...@verbum.org) wrote:
> Anyways, new tested patch attached. Lennart, any objections?
Yes. Let's not tape over problems and pretend things could work if we
freely mix and match things.
I do like Martin's original patch, since by unsetting XDG_RUNTIME_D
On Tue, 19.11.13 10:42, Colin Walters (walt...@verbum.org) wrote:
> My patch though starts to pave the way for having XDG_RUNTIME_DIR
> consistently point to that of the user's uid
I think this is just bogus. You used "su". So the UID was changed and
little else. Now you start patchign XDG_RUNTIM
Hi,
Looks good generally but two very small points:
'Twas brillig, and Colin Walters at 20/11/13 17:34 did gyre and gimble:
> +/* Ensure the XDG_RUNTIME_DIR for root always exists, so that
> + * su/sudo/pkexec all do the right thing when changing to root.
> + */
> +static int ensure_root_runtime
On Tue, 2013-11-19 at 22:38 +, Colin Guthrie wrote:
> 'Twas brillig, and Colin Walters at 19/11/13 18:13 did gyre and gimble:
> > +d /run/user/0 0755 root root 10d
>
> This should probably be 0700 like the runtime dirs usually are I think.
Ooops =/ Fixed!
> Also won't this folder be natural
'Twas brillig, and Colin Walters at 19/11/13 18:13 did gyre and gimble:
> +d /run/user/0 0755 root root 10d
This should probably be 0700 like the runtime dirs usually are I think.
Also won't this folder be naturally reaped in user_finalize() in
login/logind-user.c:
/* Kill XDG_RUNTIME_DI
On Tue, 2013-11-19 at 18:15 +0100, Martin Pitt wrote:
> For the record, I much prefer something like this to my original patch
> which simply unsets it. I just shied away from that as Lennart
> repeatedly said on the RHBZ bug that he doesn't want su behave that
> way.
This is a complex discussio
Hello,
Colin Walters [2013-11-19 10:42 -0500]:
> Both of our patch series currently are basically going to have the
> effect that with pkexec, XDG_RUNTIME_DIR is unset. But this is
> undesirable because it forces the rest of userspace to go back to the
> old dark ages when XDG_RUNTIME_DIR didn't
On Mon, 2013-11-18 at 19:35 -0500, Colin Walters wrote:
> And that's what I'm testing - with Martin's patch in the loop I was
> still getting XDG_DATA_DIR for uid 1000, I'll try to debug soon.
Ok, some discussion on IRC revealed that I was only using the second
patch to s/loginuid/uid/, but we ne
Hello Colin,
Colin Walters [2013-11-18 19:35 -0500]:
> This is on my radar; the patch wasn't working for me but I haven't had
> time to add debug prints and figure out whether it's my
> (gnome-continuous) side or something else. Give me a day or two.
Did you just try the original patch that I se
Hi,
On Mon, 2013-11-18 at 21:59 +0100, Michael Stapelberg wrote:
> Therefore, I’d like to ask people with a commit bit (Colin?) to please
> have another look and merge the patch unless something is still wrong
> with it :). Thanks!
This is on my radar; the patch wasn't working for me but I haven
Hi Martin,
Martin Pitt writes:
> Martin Pitt [2013-11-14 17:53 +0100]:
>> So option 1 is to update the patch to not rely on "uid", but instead
>> always get it from PAM.
>
> I went through all instances of using the uid, username, or pw, and I
> cannot find any place in the PAM module where we w
Martin Pitt [2013-11-14 17:53 +0100]:
> So option 1 is to update the patch to not rely on "uid", but instead
> always get it from PAM.
I went through all instances of using the uid, username, or pw, and I
cannot find any place in the PAM module where we would actually want
the originating user nam
Hello Colin,
Colin Guthrie [2013-11-14 10:28 +0100]:
> OK, I just tried this but I can't seem to make it work and prevent the
> XDG_* vars being set.
>
> I applied the attached variation to my 208 build and then ran "pkexec
> /bin/bash" which also suffers from the same problems.
>
> pkexec clean
35 matches
Mail list logo
