On Thu, 01.08.13 14:47, Stephen Gallagher (sgall...@redhat.com) wrote:
> > I can understand that it is easier to intrdouce a new userspace
> > daemon that works around a kernel limitations, but the right
> > approach is still to just fix the kernel interface.
> >
> > The kernel keyring folks work
On Fri, 02.08.13 11:52, Florian Weimer (fwei...@redhat.com) wrote:
> On 07/30/2013 03:27 AM, Lennart Poettering wrote:
>
> >The same component that creates the temporary directory?
> >
> >In pseudo code:
> >
> >char temp[] = "/tmp/krb.XX", link[PATH_MAX];
> >char *machine_id, *home;
>
On 07/30/2013 03:27 AM, Lennart Poettering wrote:
The same component that creates the temporary directory?
In pseudo code:
char temp[] = "/tmp/krb.XX", link[PATH_MAX];
char *machine_id, *home;
mkdtemp(temp);
machine_id = get_file_contents("/etc/machine_id");
*strchrnul
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/29/2013 06:50 PM, Lennart Poettering wrote:
> On Mon, 29.07.13 17:25, Simo Sorce (s...@redhat.com) wrote:
>
>>> So, one question, why again not just use the kernel keyring?
>>
>> Size.
>>
>>> If this is about the size of the objects then maybe
On Fri, Jul 26, 2013 at 07:40:39PM +0200, Lennart Poettering wrote:
> On Fri, 26.07.13 11:01, Stephen Gallagher (sgall...@redhat.com) wrote:
>
> >
> > I'm CCing Lennart and Kay on the discussion about this. Creating this
> > symlink in the oddjob would be somewhat error-prone. I'd rather that
> >
On Tue, 2013-07-30 at 08:07 -0400, Simo Sorce wrote:
> On Tue, 2013-07-30 at 03:27 +0200, Lennart Poettering wrote:
> > On Mon, 29.07.13 21:11, Simo Sorce (s...@redhat.com) wrote:
> >
> > > On Tue, 2013-07-30 at 02:08 +0200, Lennart Poettering wrote:
> > > > On Mon, 29.07.13 23:56, David Woodhouse
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/30/2013 05:57 PM, Lennart Poettering wrote:
> Fix problems where they are, don't work around them.
I think this is the crux of our disconnect here, Lennart. I appreciate
that your goal is to have a perfect solution in all projects from the
kern
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/30/2013 05:53 PM, Lennart Poettering wrote:
> On Tue, 30.07.13 08:07, Simo Sorce (s...@redhat.com) wrote:
>
>>> The same component that creates the temporary directory?
>>>
>>> In pseudo code:
>>>
>>> char temp[] = "/tmp/krb.XX", link[PATH
On Tue, 30.07.13 08:36, Stephen Gallagher (sgall...@redhat.com) wrote:
> On 07/29/2013 06:50 PM, Lennart Poettering wrote:
> > On Mon, 29.07.13 17:25, Simo Sorce (s...@redhat.com) wrote:
> >> If need be we can add a scanning cron job (or daemon or whatever)
> >> that will walk through the caches a
On Tue, 30.07.13 08:34, Stephen Gallagher (sgall...@redhat.com) wrote:
> >> The problem with /tmp is that if you want predictable filenames
> >> for the storage, you open yourself to a denial-of-service attack
> >> where another user can create a file with the same name.
> >
> > Well, but that's
On Tue, 30.07.13 08:07, Simo Sorce (s...@redhat.com) wrote:
> > The same component that creates the temporary directory?
> >
> > In pseudo code:
> >
> >char temp[] = "/tmp/krb.XX", link[PATH_MAX];
> >char *machine_id, *home;
> >
> >mkdtemp(temp);
> >machine_id = get_file_
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/30/2013 08:07 AM, Simo Sorce wrote:
> On Tue, 2013-07-30 at 03:27 +0200, Lennart Poettering wrote:
>> Of course, you should skip this if the symlink already exists and
>> points to a valid directory...
>
> This doesn't make any sense whatsoever,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/29/2013 06:50 PM, Lennart Poettering wrote:
> On Mon, 29.07.13 17:25, Simo Sorce (s...@redhat.com) wrote:
>> If need be we can add a scanning cron job (or daemon or whatever)
>> that will walk through the caches and eliminate those that have
>> e
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/29/2013 08:08 PM, Lennart Poettering wrote:
> On Mon, 29.07.13 23:56, David Woodhouse (dw...@infradead.org)
> wrote:
>
>> On Tue, 2013-07-30 at 00:50 +0200, Lennart Poettering wrote:
>>> So, why don't you revert to using /tmp then?
>>
>> The pr
On Tue, 2013-07-30 at 03:27 +0200, Lennart Poettering wrote:
> On Mon, 29.07.13 21:11, Simo Sorce (s...@redhat.com) wrote:
>
> > On Tue, 2013-07-30 at 02:08 +0200, Lennart Poettering wrote:
> > > On Mon, 29.07.13 23:56, David Woodhouse (dw...@infradead.org) wrote:
> > >
> > > > On Tue, 2013-07-30
On Mon, 29.07.13 21:11, Simo Sorce (s...@redhat.com) wrote:
> On Tue, 2013-07-30 at 02:08 +0200, Lennart Poettering wrote:
> > On Mon, 29.07.13 23:56, David Woodhouse (dw...@infradead.org) wrote:
> >
> > > On Tue, 2013-07-30 at 00:50 +0200, Lennart Poettering wrote:
> > > > So, why don't you reve
On Tue, 2013-07-30 at 02:08 +0200, Lennart Poettering wrote:
> On Mon, 29.07.13 23:56, David Woodhouse (dw...@infradead.org) wrote:
>
> > On Tue, 2013-07-30 at 00:50 +0200, Lennart Poettering wrote:
> > > So, why don't you revert to using /tmp then?
> >
> > The problem with /tmp is that if you wa
On Mon, 29.07.13 23:56, David Woodhouse (dw...@infradead.org) wrote:
> On Tue, 2013-07-30 at 00:50 +0200, Lennart Poettering wrote:
> > So, why don't you revert to using /tmp then?
>
> The problem with /tmp is that if you want predictable filenames for the
> storage, you open yourself to a denial
On 26/07/13 14:58 -0400, Colin Walters wrote:
> On Fri, 2013-07-26 at 13:57 -0400, Stephen Gallagher wrote:
> One kind of nontrivial approach, but at least worth thinking about, is
> changing cron to keep a zygote process around (with a session) for users
> with active cron jobs.
>
> Futhermore if
On Tue, 2013-07-30 at 00:50 +0200, Lennart Poettering wrote:
> So, why don't you revert to using /tmp then?
The problem with /tmp is that if you want predictable filenames for the
storage, you open yourself to a denial-of-service attack where another
user can create a file with the same name.
It'
On Mon, 29.07.13 17:25, Simo Sorce (s...@redhat.com) wrote:
> > So, one question, why again not just use the kernel keyring?
>
> Size.
>
> > If this is about
> > the size of the objects then maybe you can convince the kernel keyring
> > guys to make it backed by tmpfs, the same way as GEM/DRM or
On Mon, 2013-07-29 at 22:50 +0200, Lennart Poettering wrote:
> On Fri, 26.07.13 10:48, Simo Sorce (s...@redhat.com) wrote:
>
> (Coming back to the original suggestion, now that the XDG_RUNTIME_DIR
> thing is ruled out.)
>
> > Recently a number of bugs [1-5] have come up regarding the new default
On Fri, 26.07.13 10:48, Simo Sorce (s...@redhat.com) wrote:
(Coming back to the original suggestion, now that the XDG_RUNTIME_DIR
thing is ruled out.)
> Recently a number of bugs [1-5] have come up regarding the new default
> Kerberos Ccache location that we changed according to [6].
>
> We orig
On Sat, 2013-07-27 at 18:23 +0200, Lennart Poettering wrote:
> On Fri, 26.07.13 15:03, Stephen Gallagher (sgall...@redhat.com) wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On 07/26/2013 02:52 PM, Lennart Poettering wrote:
> > > On Fri, 26.07.13 14:32, Stephen Gallagher (
On Fri, 26.07.13 15:03, Stephen Gallagher (sgall...@redhat.com) wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 07/26/2013 02:52 PM, Lennart Poettering wrote:
> > On Fri, 26.07.13 14:32, Stephen Gallagher (sgall...@redhat.com)
> > wrote:
> >
> >> As Simo noted in the other thread
On Fri, 2013-07-26 at 12:22 -0400, Stephen Gallagher wrote:
> Well, *users* should not really notice or care where these things are
> unless they go looking for them. All a user cares about is whether
> they can authenticate and have access to their SSO credentials after
> doing so.
>
> Moving th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/26/2013 02:52 PM, Lennart Poettering wrote:
> On Fri, 26.07.13 14:32, Stephen Gallagher (sgall...@redhat.com)
> wrote:
>
>> As Simo noted in the other thread, the availability of
>> credentials outside the normal user session is an expectation o
On Fri, 2013-07-26 at 13:57 -0400, Stephen Gallagher wrote:
> 2) We still need to consider use-cases where a cron job or other
> long-running service needs to use credentials given to it by the user,
> though they are no longer signed in. With the current approach, we
> still need to be concerned
On Fri, 26.07.13 14:32, Stephen Gallagher (sgall...@redhat.com) wrote:
> As Simo noted in the other thread, the availability of credentials
> outside the normal user session is an expectation of existing tools.
> The exposure here is significantly mitigated by the fact that Kerberos
> credentials
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/26/2013 02:40 PM, Lennart Poettering wrote:
> On Fri, 26.07.13 14:20, Simo Sorce (s...@redhat.com) wrote:
>
>> We want this thing to work by default, having normal users to
>> find out this lingering concept exist because operations that
>> curr
On Fri, 26.07.13 14:20, Simo Sorce (s...@redhat.com) wrote:
> We want this thing to work by default, having normal users to find out
> this lingering concept exist because operations that currently works
> start failing is already a big failure.
OK, this is the deal-breaker. The thing about XDG_R
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/26/2013 02:15 PM, Lennart Poettering wrote:
> On Fri, 26.07.13 13:57, Stephen Gallagher (sgall...@redhat.com)
> wrote:
>
>> This would help us out on the 'su -l' and 'sudo -i' cases, but
>> it still potentially leaves us with two problems that I
On Fri, 2013-07-26 at 20:15 +0200, Lennart Poettering wrote:
> On Fri, 26.07.13 13:57, Stephen Gallagher (sgall...@redhat.com) wrote:
>
> > This would help us out on the 'su -l' and 'sudo -i' cases, but it
> > still potentially leaves us with two problems that I'm not sure how to
> > solve (withou
On Fri, 26.07.13 13:57, Stephen Gallagher (sgall...@redhat.com) wrote:
> This would help us out on the 'su -l' and 'sudo -i' cases, but it
> still potentially leaves us with two problems that I'm not sure how to
> solve (without breaking the XDG_RUNTIME_DIR lifecycle definition).
>
> 1) https://b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/26/2013 01:40 PM, Lennart Poettering wrote:
> On Fri, 26.07.13 11:01, Stephen Gallagher (sgall...@redhat.com)
> wrote:
>
>>
>> I'm CCing Lennart and Kay on the discussion about this. Creating
>> this symlink in the oddjob would be somewhat erro
On Fri, 26.07.13 11:01, Stephen Gallagher (sgall...@redhat.com) wrote:
>
> I'm CCing Lennart and Kay on the discussion about this. Creating this
> symlink in the oddjob would be somewhat error-prone. I'd rather that
> we ask logind to carry a patch just for F19 where the creation of
> XDG_RUNTIME
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/26/2013 11:31 AM, Miloslav Trmač wrote:
> On Fri, Jul 26, 2013 at 5:17 PM, Simo Sorce
> wrote:
>> On Fri, 2013-07-26 at 17:07 +0200, Tomas Mraz wrote:
For the record, I like this plan. It should also serve to
address a number of unfort
On Fri, Jul 26, 2013 at 5:17 PM, Simo Sorce wrote:
> On Fri, 2013-07-26 at 17:07 +0200, Tomas Mraz wrote:
>> > For the record, I like this plan. It should also serve to address a
>> > number of unfortunate edge-cases, particularly those around the
>> > semi-sessions created by 'su' and 'sudo'.
>>
On Fri, 2013-07-26 at 17:07 +0200, Tomas Mraz wrote:
> > For the record, I like this plan. It should also serve to address a
> > number of unfortunate edge-cases, particularly those around the
> > semi-sessions created by 'su' and 'sudo'.
>
> I'd rather like to see a plan that would fix also other
On Fri, 2013-07-26 at 11:01 -0400, Stephen Gallagher wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 07/26/2013 10:48 AM, Simo Sorce wrote:
> > Recently a number of bugs [1-5] have come up regarding the new
> > default Kerberos Ccache location that we changed according to [6].
> >
On Fri, 2013-07-26 at 11:01 -0400, Stephen Gallagher wrote:
> On 07/26/2013 10:48 AM, Simo Sorce wrote:
> > Recently a number of bugs [1-5] have come up regarding the new
> > default Kerberos Ccache location that we changed according to [6].
> >
> > We originally thought that reusing the same dir
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/26/2013 10:48 AM, Simo Sorce wrote:
> Recently a number of bugs [1-5] have come up regarding the new
> default Kerberos Ccache location that we changed according to [6].
>
> We originally thought that reusing the same directory used by
> XDG_US
Recently a number of bugs [1-5] have come up regarding the new default
Kerberos Ccache location that we changed according to [6].
We originally thought that reusing the same directory used by
XDG_USER_DIR was a good idea as systemd/logind would pre-create it for
us and we'd all be happy.
Unfortun
43 matches
Mail list logo
