Mailing List Archive

problems with access rights
Hi,

to get a shared group calendar I created an account with NO "group" role
set. I the created accounts and gave them all full rights to the group
via a newly defined "is member of" relationship. I did not set any other
relationships.
But now everybody has full rights to everybody.

Here some parts of the database content:

davical=# SELECT * from relationship where from_user = 1001;
from_user | to_user | rt_id
-----------+---------+-------
1001 | 1009 | 12

davical=# select * from relationship_type where rt_id=12;
rt_id | rt_name | rt_togroup | confers | rt_fromgroup
-------+--------------+------------+---------+--------------
12 | is member of | | A |

davical=# select * from role_member where user_no = 1009;
role_no | user_no
---------+---------
(0 rows)

davical=# SELECT get_permissions(1001,1010);
get_permissions
-----------------
A


========
as you can see, get_permissions returns an A for the permission. I guess
there is a bug in the stored procedure but did not look into it.

regards, Andreas
problems with access rights [ In reply to ]
Hi,

I've read this before.
As I've written, this not a "real" group, meaning there is no group
attribute set. So this is more or less a case of
"When the relationship is to a normal user"

regards, Andreas

Andrew McMillan wrote:
> On Wed, 2009-09-30 at 09:25 +0200, Andreas Kuntzagk wrote:
>> Hi,
>>
>> to get a shared group calendar I created an account with NO "group" role
>> set. I the created accounts and gave them all full rights to the group
>> via a newly defined "is member of" relationship. I did not set any other
>> relationships.
>> But now everybody has full rights to everybody.
>
> http://wiki.davical.org/w/How_Do_Relationships_Work
>
> Check under 'When the relationship is to a "group"', and most
> particularly, read the section under "If there are no further
> relationships'.
>
> Cheers,
> Andrew.
>
> PS. Yes, it probably was a bad idea, but that's the way it was designed,
> written and documented. I didn't then realise how often it would be
> unexpected behaviour :-)
>
>
> ------------------------------------------------------------------------
> andrew (AT) morphoss (DOT) com +64(272)DEBIAN
> You will pass away very quickly.
> ------------------------------------------------------------------------
>
problems with access rights [ In reply to ]
On Wed, 2009-09-30 at 11:03 +0200, Andreas Kuntzagk wrote:
> Hi,
>
> I've read this before.
> As I've written, this not a "real" group, meaning there is no group
> attribute set. So this is more or less a case of
> "When the relationship is to a normal user"

OK. You didn't show the result of:

select role_member join role_name using(role_no) where user_no = 12;

So I assumed that user 12 had the 'Group' role set...

Cheers,
Andrew.
>
> regards, Andreas
>
> Andrew McMillan wrote:
> > On Wed, 2009-09-30 at 09:25 +0200, Andreas Kuntzagk wrote:
> >> Hi,
> >>
> >> to get a shared group calendar I created an account with NO "group" role
> >> set. I the created accounts and gave them all full rights to the group
> >> via a newly defined "is member of" relationship. I did not set any other
> >> relationships.
> >> But now everybody has full rights to everybody.
> >
> > http://wiki.davical.org/w/How_Do_Relationships_Work
> >
> > Check under 'When the relationship is to a "group"', and most
> > particularly, read the section under "If there are no further
> > relationships'.
> >
> > Cheers,
> > Andrew.
> >
> > PS. Yes, it probably was a bad idea, but that's the way it was designed,
> > written and documented. I didn't then realise how often it would be
> > unexpected behaviour :-)
> >
> >
> > ------------------------------------------------------------------------
> > andrew (AT) morphoss (DOT) com +64(272)DEBIAN
> > You will pass away very quickly.
> > ------------------------------------------------------------------------
> >
>


------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Harp not on that string.
-- William Shakespeare, "Henry VI"

------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20091001/727e340e/attachment.pgp>
-------------- next part --------------
problems with access rights [ In reply to ]
Hi,

Andrew McMillan wrote:
> On Wed, 2009-09-30 at 11:03 +0200, Andreas Kuntzagk wrote:
>> Hi,
>>
>> I've read this before.
>> As I've written, this not a "real" group, meaning there is no group
>> attribute set. So this is more or less a case of
>> "When the relationship is to a normal user"
>
> OK. You didn't show the result of:
>
> select role_member join role_name using(role_no) where user_no = 12;

This gives me an 'syntax error at or near "join"'
Anyway there is no user_no 12; (12 is the id of the relationship) I
already showed you the _complete_ role_member table:

davical=# select * from role_member ;
role_no | user_no
---------+---------
1 | 1
(1 row)
davical=# select * from roles;
role_no | role_name
---------+-----------
1 | Admin
2 | Group
3 | Public
4 | Resource
(4 rows)

So _nobody_ has the "Group" role set. I still suspect an obscure bug in
the stored procedure but I'm not SQL expert enough to find it.

For testing purposes I will create an additional user, set the
relationship and the see what get_permission gives me.

regards, Andreas

> So I assumed that user 12 had the 'Group' role set...
>
> Cheers,
> Andrew.
>> regards, Andreas
>>
>> Andrew McMillan wrote:
>>> On Wed, 2009-09-30 at 09:25 +0200, Andreas Kuntzagk wrote:
>>>> Hi,
>>>>
>>>> to get a shared group calendar I created an account with NO "group" role
>>>> set. I the created accounts and gave them all full rights to the group
>>>> via a newly defined "is member of" relationship. I did not set any other
>>>> relationships.
>>>> But now everybody has full rights to everybody.
>>> http://wiki.davical.org/w/How_Do_Relationships_Work
>>>
>>> Check under 'When the relationship is to a "group"', and most
>>> particularly, read the section under "If there are no further
>>> relationships'.
>>>
>>> Cheers,
>>> Andrew.
>>>
>>> PS. Yes, it probably was a bad idea, but that's the way it was designed,
>>> written and documented. I didn't then realise how often it would be
>>> unexpected behaviour :-)
>>>
>>>
>>> ------------------------------------------------------------------------
>>> andrew (AT) morphoss (DOT) com +64(272)DEBIAN
>>> You will pass away very quickly.
>>> ------------------------------------------------------------------------
>>>
>
>
> ------------------------------------------------------------------------
> andrew (AT) morphoss (DOT) com +64(272)DEBIAN
> Harp not on that string.
> -- William Shakespeare, "Henry VI"
>
> ------------------------------------------------------------------------
>
problems with access rights [ In reply to ]
> OK. Obviously I'm overtired and reading the previous e-mail in too much
> of a hurry :-)
>
> Sorry about that.

No problem, thanks for working on this at all.

> There is one bug in get_permissions() which was fixed recently, but
> overall I am concentrating on trying to write a new permissions model
> which is perhaps why I'm trying not to think too hard about this bug in
> the old one...
>
> As it stands the logic is pretty arcane, but the main problem is it is
> inefficient as well.

Unfortunately I advertised davical to my boss before encountering this
problem. (My fault, I should have tested)

>> For testing purposes I will create an additional user, set the
>> relationship and the see what get_permission gives me.

This showed the problem:
I created user1, user2 and user3 with no role, gave user2 and user3 "A"
permission on user1 and "voila!" user2 has "A" on user3 (and vice versa)
BTW. this is not restricted to "A" relationships, but works with others.
It just behaves _as_if_ user1 has the "group" role set according to your
documentation.

> You might want to try grabbing the latest caldav_functions.sql from the
> repository, since there was a bug fixed in the expansion of 'A'
> privileges, which might apply in this case.

I will try this.

One other thing: Would it be possible to make user credential be used
on the level of "servername/davical/caldav.php/<username>" instead of
servername/davical/caldav.php ? This way I can't use to different users
credentials for different calendars on the same davical server. But I
don't know if this is a problem of the implementation, CalDAV or Lightning.

Sleep well! (I'm starting work right now)

Andreas
problems with access rights [ In reply to ]
On Thu, 2009-10-01 at 09:51 +0200, Andreas Kuntzagk wrote:
>
> Unfortunately I advertised davical to my boss before encountering this
> problem. (My fault, I should have tested)

Yeah, well we'll try and resolve it, regardless :-)


> >> For testing purposes I will create an additional user, set the
> >> relationship and the see what get_permission gives me.
>
> This showed the problem:
> I created user1, user2 and user3 with no role, gave user2 and user3 "A"
> permission on user1 and "voila!" user2 has "A" on user3 (and vice versa)
> BTW. this is not restricted to "A" relationships, but works with others.
> It just behaves _as_if_ user1 has the "group" role set according to your
> documentation.
>
> > You might want to try grabbing the latest caldav_functions.sql from the
> > repository, since there was a bug fixed in the expansion of 'A'
> > privileges, which might apply in this case.
>
> I will try this.

http://repo.or.cz/w/davical.git?a=blob;f=dba/caldav_functions.sql;hb=HEAD

If you load that file into current DAViCal you will get an error for the
last function. This can be ignored - the table which that applies to is
not yet in a released copy of DAViCal.


> One other thing: Would it be possible to make user credential be used
> on the level of "servername/davical/caldav.php/<username>" instead of
> servername/davical/caldav.php ? This way I can't use to different users
> credentials for different calendars on the same davical server. But I
> don't know if this is a problem of the implementation, CalDAV or Lightning.

If I understand what you are after here, I think the problem is a
Lightning issue.

https://bugzilla.mozilla.org/show_bug.cgi?id=247486


> Sleep well! (I'm starting work right now)

Thanks, I should do that :-)

Cheers,
Andrew.

------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Wrinkles should merely indicate where smiles have been.
-- Mark Twain

------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20091001/f6a9ae1f/attachment-0001.pgp>
-------------- next part --------------
problems with access rights [ In reply to ]
I think I may have found the problem:

In this part of get_permission() you don't check for the role of the
involved users: (this is at the end of the function)

SELECT rt1.confers INTO out_confers, tmp_confers1 FROM relationship r1
JOIN relationship_type rt1 ON ( r1.rt_id = rt1.rt_id )
LEFT OUTER JOIN relationship r2 ON ( rt1.rt_id = r2.rt_id )
WHERE r1.from_user = in_from AND r2.from_user = in_to AND
r1.from_user != r2.from_user AND r1.to_user = r2.to_user
AND NOT EXISTS( SELECT 1 FROM relationship r3 WHERE r3.from_user
= r1.to_user ) ;

I would add that check if my SQL knowledge would be fresh. Maybe I will
comment out this for now. ATM I don't plan to use more sophisticated
relationships so I probably don't need this in-depth checking.

regards, Andreas
problems with access rights [ In reply to ]
On Thu, 2009-10-01 at 14:19 +0200, Andreas Kuntzagk wrote:
> I think I may have found the problem:
>
> In this part of get_permission() you don't check for the role of the
> involved users: (this is at the end of the function)
>
> SELECT rt1.confers INTO out_confers, tmp_confers1 FROM relationship r1
> JOIN relationship_type rt1 ON ( r1.rt_id = rt1.rt_id )
> LEFT OUTER JOIN relationship r2 ON ( rt1.rt_id = r2.rt_id )
> WHERE r1.from_user = in_from AND r2.from_user = in_to AND
> r1.from_user != r2.from_user AND r1.to_user = r2.to_user
> AND NOT EXISTS( SELECT 1 FROM relationship r3 WHERE r3.from_user
> = r1.to_user ) ;

Ah, true.

It should be enough to just tack:

AND usr_is_role(r1.to_user,'Group')

into the end of that SQL.


> I would add that check if my SQL knowledge would be fresh. Maybe I will
> comment out this for now. ATM I don't plan to use more sophisticated
> relationships so I probably don't need this in-depth checking.

Commenting it out is also a good option, or just

RETURN '';

before that part.

Cheers,
Andrew.

------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Your aim is high and to the right.
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20091002/cb2fa593/attachment.pgp>
-------------- next part --------------