Can you paste the contents of the group-member-set property of the user
role? If you notice the root user doesn't have any explicit rights to
the /files node, everything is inherited through the root role. My guess
is your user isn't making it into the role properly.
-James
Krishna Kankipati wrote:
Jason,
I checked the acl for this folder, it looks like this:
ACL for /Slide/files/folder1:
------------------------------------------------------------
granted to /Slide/roles/user (not protected) (not inherited)
DAV:all
DAV:write
granted to property (not protected) (inherited from '/Slide/files')
DAV:read-acl
granted to /Slide/roles/root (not protected) (inherited from '/Slide/')
DAV:all
granted to all (not protected) (inherited from '/Slide/')
DAV:read
------------------------------------------------------------
I added my user 'user1' to role called 'user' using group-member-set
property (also checked it). Since the role 'user' has the permissions to
write to folder 'folder1', as seen by the ACL output, and there seems to be
no contradiction to any other ace's in the acl list, I expected my user
'user1' to have necessary permissions to upload a file to 'folder1'. But I
get 403 forbidden error. I can login as root and using the same command can
upload a file to 'folder1'. So, I am not sure whats wrong. Initially I
thought may be the group-member-set is not set properly, so used DAVExplorer
to do the same with no avail. Do you think I am missing something, how do I
debug this situation?
thanks,
regards,
Krishna
-----Original Message-----
From: James Mason [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 04, 2004 2:34 PM
To: Slide Users Mailing List
Subject: Re: User Authorization based on permissions set to role in
Slide2.1
Krishna,
Permissions on a role are inherited by the members of that role, yes.
One thing to check is that your user isn't being denied write access but
another ACL that's higher in the list. ACLs are checked in order and the
first one that applies takes precedence. If user1 is in a role that has
been denied the ability to write, and that ACE appears in the ACL before
the permission that grants write access, user1 will not have write access.
-James
Krishna Kankipati wrote:
Hi Folks,
I am re-posting this mail since I haven't got any replies yet. I am
hoping there is some developer there who might have tried to play around
with permissions in Slide2.1M1. My problem is that when I assign some
permissions to a role, those permissions are not propogated to the users
in
that role. If not for permissions what else is the purpose of having roles
at all? I am sure it is not just for logical grouping of users. Any help
is
appreciated ......
thanks in advance ....
regards,
Krishna
-----Original Message-----
From: Krishna Kankipati
Sent: Tuesday, August 03, 2004 5:47 PM
To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED]
Subject: User Authorization based on permissions set to role in
Slide2.1
Michael,
I was searching the mail archive for some help on permissions and
came upon this discussion you were having with some developer which seemed
relevant to my question:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg05056.html
Does slide permissions propogate based on role memberships. I mean, if I
create a role called "role1", and add a user called "user1" to it, will
user1 get all the permissions that are assigned to role1. I've seen in my
tests that although I gave enough "write" permissions to "role1", Slide
does not allow "user1" to write unless I add the "write" permission to
"user1" itself. Am I missing something or is it a bug. What is your
opinion on this? I am using Slide 2.1M1 and command line client to grant
permissions to /Slide/files collection.
thanks
regards,
Krishna
Krishna Kankipati
Software Engineer
SSA Global
* 1626 Cole Blvd. Golden, CO 80401, USA
* 303-274-3027
Fax: 303-274-3137
* [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
