[Owncloud] Users LDAP storage related issues

[Michael Gapczynski]

On Saturday, March 03, 2012 04:50:42 PM Jeroen van Meeuwen wrote:
> On 2012-03-03 15:27, Michael Gapczynski wrote:
> > On Saturday, March 03, 2012 12:20:02 PM Jeroen van Meeuwen wrote:
> >> On 2012-02-29 19:46, Arthur Schiwon wrote:
> >> > On Tuesday 28 February 2012 14:27:36 Aleksander Machniak wrote:
> >> >> - Authenticating against LDAP does not create the owncloud
> >> >> equivalent of
> >> >> a user account, and therefore sharing with permissions is not
> >> >> working,
> >> > 
> >> > These are two different things. Sharing with permissions is not
> >> > dependent on
> >> > local accounts. Is there another reason for them?
> >> 
> >> Correct me if I'm wrong, but I thought ownCloud saved the (user,
> >> group)
> >> permissions on files shared, amongst other things, in it's own
> >> database.
> >> 
> >> I'm seeing owncloud.oc_sharing be filled with a uid_owner (my LDAP
> >> UID), and I'm seeing sharing only be possible with local database
> >> user
> >> accounts (not other LDAP accounts).
> >> 
> >> I think it is easiest to acknowledge the users end up in the
> >> database's
> >> users table, with a proper user_id, and refer back to that user_id
> >> in
> >> other tables (such as sharing) instead of continuously referring to
> >> a
> >> 'uid' - because of renames of people.
> >> 
> >> The same goes for groups, really, and ultimately you may want to
> >> indicate the authentication and authorization database (type) these
> >> users could have originally come from (i.e. the users and groups
> >> tables
> >> get an LDAP tree identifier added to them).
> >> 
> >> If you wanted, you could then detect renames by adding yet another
> >> column that holds the persistent, unique identifier for LDAP entries
> >> (usually entryUUID, or nsUniqueID, or something custom).
> >> 
> >> You would then search for the entry in LDAP, get its unique
> >> identifier,
> >> search your own tables for said identifier, either create a new
> >> entry or
> >> update an existing entry.
> >> 
> >> Alternatively, some sort of API call could cause a synchronization
> >> daemon (Kolab does this a lot, I'm working on the parts that make
> >> this
> >> happen for Roundcube at this very moment), to issue a rename, add or
> >> delete.
> > 
> > Sharing is already possible with LDAP users and other user backends.
> 
> It seems though selecting users from our LDAP tree (in the sharing
> dialog for a file) does not function as well as one might expect.

Is the sharing dropdown not populated with the LDAP users? This may be a user 
interface issue rather than a problem with the sharing backend. You could try 
manually inserting a item into the sharing table with the uid_shared_with set 
to a LDAP user. 

I also have some changes to the user interface for sharing on my todo list. A 
dropdown is not reasonable for large LDAP user directories. 

> 
> If I upload a file, and share it, the uid_owner is correctly attributed
> to me, but all I succeed in sharing the file with is any of the local
> user accounts.
> 
> Could it be that, since we use the displayName attribute for LDAP
> users, ownCloud is not digesting the selection?
> 
> If you want, I can give you an account on our installation and you
> could see for yourself.
> 
> > There is no direct link between the database users table and the
> > sharing table.
> > 
> > I'm aware that our method of keeping track of users in the database
> > is not
> > good and can cause problems with renames. This applies to more than
> > just
> > sharing. This is on my todo list for the next release.
> 
> If you need/want some help with this, feel free to drop me a line.
> 
> Kind regards,
> 
> Jeroen van Meeuwen