Group Security, Must grant rights to Root, 3.1.2 Upgrade

[jmayes]

Hello!

I upgraded my Vault repository last night to 3.1.2. It would appear as if the way in which access is granted has changed. I primarily use group rights and I have a simple structure like

$
$\clients
$\clients\A
$\clients\B
$\clients\C
$\clients\C\somedir

where I was able to assign a group specific rights to a nested level such as ($\clients\C\somedir) without assigning any rights to its parent(s). I find that I must now assign Read to the root ($) in order for people to even gain access to the repository. This obviously results in inherited Read access to all children (in this case many of other my clients! )

I have verified each users' individual rights assignments (Users Tab, [select user], Security button) and can confirm that the users only have rights granted through their respective groups.

I decided to manually handle the issue for now through "Folder Security" settings but it is rather tedious (denying read to individual folders). Additionally, the admin client will generate a .NET Unhandled Exception after hanging. I have yet to try to generate the steps to reproduce this on a reliable basis but would be willing to do so should it be news to the vault testing team.

Does anyone have any suggestions? This is the first upgrade problem I have experienced with the Vault product thus far. I assume that a "downgrade" isn't possible... although I do have backups -- it just seems messy.

Regards,
James

[jclausius]

James, can you provide a simple example for the following tree:

$/
$/clients/
$/clients/A/
$/clients/B/
$/clients/C/
$/clients/C/Sub/

Given user X, what are user X's default rights. What groups contain user X? What are all the group security settings?

I'd like to have a look at your setup.

Note, there have been some changes in Vault 3.1 due to some customer feedback, but I think there is enough "new" feedback that this will be revisited in a later release.

[jmayes]

Hi Jeff. I've attached some screenshots. I hope they help.

In "2_UserRights.jpg" you can see where I manually added (R)ead in order for user sadams to view any items at all in the repo. This was not the case in 3.0.x prior to my upgrade.

James

[jclausius]

I'll take a look at your setup. Thanks.

[jclausius]

I just re-created your test setup ($/clients/ccg/dae/requirements/), including the $/chorus/ directory on a Vault 3.1.2.3511 Server.

After configuration, my user was able to log in and see the repository. I was able to do actions under ccg except for the dae/requirements sub directory.

So Vault does seem to be acting correctly against a new installation.


I wonder if there is something in the database we're not seeing in the Admin Tool.

Can you provide the information for the following SQL Queries. You could email the results if you would like a bit more privacy.

Code: Select all

DECLARE @userid int, @repid int;

SELECT @userid = userid FROM sgvault.dbo.tblusers WHERE login = 'sadams';

SELECT @repid = repid FROM sgvault.dbo.tblrepositories WHERE name = N'Software';

SELECT * FROM sgvault.dbo.ufngetusersecurityrights(@repid, @userid, -1);

[jmayes]

Hi again, attached is a screenshot from query analyzer...

[jclausius]

From this, it looks like sadams only has read-only access (from the user) to the repository at $/.

When sadams logs in, is that the case?

[jmayes]

That is correct. If I don't grant him readonly access to $ he can't see any items in the repo. He gets a message stating:

"You have no rights to view any items in the repository."

The client doesn't disconnect him after that, it's just that he sees nothing in his treeview.

James

[jclausius]

I have one other suggestion before we look at this from a different angle.

After removing the user "read right" on $/ is it possible to have sadams log on from a machine he/she has never used before? I'd like to know if you see the same behavior on a machine which sadams has no cached information.

[jmayes]

I get the same result on a brand new machine with a fresh install of the 3.1.2 client and the user sadams.

[jclausius]

In cases like these about the only option left is uploading a copy of the sgvault database in for inspection. Note, since this has nothing to do with file uploads/downloads, you can remove the contents of files to reduce overall upload time.

Is this a viable option in your case?

[jclausius]

One thing I just noticed. The SQL code you executed shows no default rights and Read rights on $ for the user.

However, it doesn't look like any GROUP rights have been assigned. What does the SQL query look like after the user is included in DAE Development Team Group?

Let's also try this query:

Code: Select all

SELECT gm.groupid, g.name FROM sgvault.dbo.tblgroupmembers gm INNER JOIN sgvault.dbo.tblgroups g ON g.groupid = gm.groupid WHERE gm.userid = 4

[jclausius]

Scratching my head some more on this one. There was a bug fixed in Vault 3.1.3, which should be released in the next couple of days. I wonder if what you are seeing is related to that bug fix.

If you are up to it we could:

1) Back up the sgvault database.
2) Run the SQL Script in the database.
3) Try to log in w/ Group privileges.

I'm wondering if this bug is related to what you're seeing.

[jmayes]

I am going through your last two replies. Here's the output from the group/groupmember query.

[jmayes]

Success! The SQL script you had me run seems to have worked. I removed all user rights for sadams and now sadams can see only the specific branches assigned without the need for Read on $ and subsequent inherited read privs.

Should I restore and wait for an official 3.1.3? Or can I run with your SQL fix and be fine?

Much thanks!
James