[Authentication] Problem with race on create collection

[Michael Leupold]

Hi Stef,

2010/9/12 Stef Walter <stefw at gnome.org>:
> When two applications (or two instances of the same app) look for a
> certain collection (such as the default collection) and it doesn't
> exist, often they'll both try to create that collection.
>
> However our current API does not have a way to handle these race
> conditions. In fact each caller of CreateCollection() is guaranteed a
> new collection.
>
> Therefore in the above case, the user is prompted twice to create two
> collections with the same name, but end up being two different collections.
>
> We can see this with gnome-keyring if a new user has no keyrings after
> login (ie: the gnome-keyring pam module is not in use). Multiple
> applications try to store passwords, which results in multiple prompts
> of the user and multiple keyrings. Not an optimal situation.
>
> One way to fix this in the API, we may want to add a 'Name' property to
> org.freedesktop.Secrets.Collection. This property roughly corresponds to
> the leaf of the collection's dbus object-path. That is for a collection:
>
> /org/freedesktop/secrets/collection/mytest
>
> The 'Name' property would be 'mytest'
>
> When creating a collection, we pass a set of properties for the new
> collection to CreateCollection(). In order to solve the above problem we
> (optionally) additionally pass the 'Name' property to CreateCollection().
>
> If such a collection already exists then it is returned instead of
> creating a new collection.
>
> Or we could make the spec so an error is returned for 'already exists'.
> I'm fine with this either way.
>
> With the above we may need one additional error code:
>
>   org.freedesktop.Secret.Error.BadName:
>   For names that are not supported or are bad.
>
> How does that sound?

One problem I see with this is that it kind of works towards the same
goal aliases do, ie. applications concurrently wishing to create a new
default collection because there's none yet would use "default" as the
name property. One of the two would succeed and set the "default"
alias to point at the collection named "default". This seems sort of
redundant. Unfortunately it isn't a real replacement for using aliases
as the Name is only available on creating a collection and you can't
change it as the objectpath is guaranteed to stay the same.

How about merging the two, making it possible to add an Alias argument
to CreateCollection? During CreateCollection it would work the same as
the Name property you described, when done with creation it creates a
new alias and sets it to point to the new collection. Additional
benefits:
- No need for a new property, no need to store it
- No need to decide what to do if two files containing collections
with the same Name property are found

I wouldn't necessarily mix Alias into the properties argument but
create an extra string argument which would be left empty if no alias
should be created.

What do you think?

Regards,
Michael