David,
Sorry I wasn't more clear. Yes you're right. Obviously if you are managing
security through a third party product then wiping the .def.xml permissions is
not appropriate.
Using Slide 2.1 and the Text stores the permission problem does exist, and can
get a bit confusing when first looking at the security. Because it hadn't been
stated anywhere I would have expected that the Domain.xml overrides security
already in place. What I found was that new permissions written to the
Domain.xml are added to existing ones and this lead to confusing problems. Once
you understand that Domain.xml doesn't replace any of the permissions already
set, then it starts to make more sense.
Thanks for the tip on Oracle JDBC store. Useful to know.
Have you thought about inserting your temporary ACL above the existing ones?
Since SLIDE will stop processing on the first direct hit it will take the
earliest entry in the list. Just a thought.
Rgrds
Phil
-----Original Message-----
From: delbd [mailto:[EMAIL PROTECTED]
Sent: Tue 14/06/2005 09:17
To: Slide Users Mailing List
Cc:
Subject: Re: ACL problem
Hi Phil,
if you mean that removing ACL from Domain.xml should remove them from
slide, i
do not agree with you. Domain.xml contains data that must be put in
slide,
however, that does not mean existing datas has to be discarded. If i
put a
permission on a Collection using DAVExplorer, i don't want to see this
permission removed each time i restart the application just because
it's not
in my Domain.xml, so on this point i'll consider the fact old ACL are
not
removed as an excpected behaviour, same goes for node metadatas and
everything else in Domain.xml.
Now if you mean new ACLs do not get read from Domain.xml when Domain.xml
changes, i can tell the problem does not arise with slide 2.1 and the
oracle
jdbc store.
I also have to mention a strange behaviour of ACL, they are not
implemented as
Access Control List, but as Access control Set (aka duplicates entries
are
not allowed), and this lead to some management problems, especially
when you
want to add a temporary rule on top of the acl and the pair
principal+action
already exist for the node.
This for example is impossible to do on a node:
/roles/manager all allow
all /actions/read deny
/roles/manager all allow
all /action/read allow
However there are cases when the app may want to put a specific set of
ACLs on
top of an existing one for a specific period of time.
Regards
--
David Delbecq
Royal Meteorological Institute of Belgium
-
Is there life after /sbin/halt -p?
Le Mardi 14 Juin 2005 09:49, Burnside, Phillip (UK - Glasgow) a écrit :
> Carlos,
>
> On investigation I found an issue with the permissions. They don't get
> flushed from any existing .def.xml files. So if you change the
permission
> in the Domain.xml and re-start you are not necessarily going to get
what
> you think you have set. The only way I found to sort this out was to
> comment out the permission block in the .def.xml and then re-start.
The new
> permissions go in place nicely. I haven't looked at whether the same
> problem exists in a relational store.
>
> If you get the metrics, I would be very interested in them also.
>
> Thanks in advance
> Phil
>
> -----Original Message-----
> From: Carlos Proal [mailto:[EMAIL PROTECTED]
> Sent: Mon 13/06/2005 22:52
> To: Slide Users Mailing List
> Cc:
> Subject: RE: ACL problem
>
>
>
>
> Great, im understanding more about how it works; digging in the
archive
> i also find important information about the relevant order the
> permissions must have.
> Its a little weird the way DavExplorer and command line handle
this
> order, anyone understand the logic ?? theorically each "add"
must be on
> top of the current permissions (at least in my mind) but it
seems that
> doesnt work that way. I'll play a little with the clients (even
the
> source code) to learn more about it.
>
> btw, im plannig to deploy the software on production with about
8,000
> users and more than 100,000 files, anyone has any usage
benchmark ??
>
> thanx again
> Carlos
>
>
> On Mon, 2005-06-13 at 22:17 +0100, Burnside, Phillip (UK -
Glasgow)
>
> wrote:
> > Carlos,
> >
> > If you revoke the access by using the negative="true"
parameter for the
> > permission which gives all students access to the folder,
then specify
> > role or user to have access then this should sort you out.
> >
> > Hth
> > Phil
> >
> > Phillip Burnside
> > Deloitte MCS Ltd
> >
> > Direct: +44 (0)14 1304 5271
> > Main: +44 (0)14 1204 2800
> > Mobile: +44 (0)79 7969 2695
> >
> > [EMAIL PROTECTED]
> > www.deloitte.co.uk
> >
> >
> > -----Original Message-----
> > From: Carlos Proal [mailto:[EMAIL PROTECTED]
> > Sent: 13 June 2005 18:24
> > To: slide-user@jakarta.apache.org
> > Subject: ACL problem
> >
> >
> >
> > hi all.
> >
> > Im developing my first webdav application so im totally
newbie on this.
> > Basically is an scholar module where i want to create folders
for each
> > subject, the teacher must have full access (read & write) and
the
> > students read only, but important: restricted to his/her
courses.
> >
> > Let me review what i have done:
> >
> > For instance the default configuration allow everybody to
write inside
> > the "files" directory, so i have removed this.
> >
> > The root user is part of the users role, and i think is not
desired in
> > my case because root must have full access to everything and
if i use
> > some deny involving the users role, root will be affected
too; so i
> > removed root from users role.
> >
> > I have created a folder for MA123 (Math) as root and gave
full access
> > to john, now john can read and write on his folder perfectly
but still
> > remains a problem, everybody has read access* to MA123 (yeah
i have a
> > copyright issue) so, how can i deny read access to everybody
else except
> > john and his students?, i suppose there must be a way to do a
deny all
> > and then grant the students (individually or by group).
> >
> > *By default everybody has read access from "/", apparently
because a
> > user needs to read roles/actions, but its inherited to
"files" and i
> > cant get rid of it, because appears several errors if i do it.
> >
> > ACL for /slide/files/MA123:
> > ------------------------------------------------------------
> > granted to /slide/users/john (not protected) (not
inherited)
> > DAV:all
> > granted to unauthenticated (not protected) (inherited
from
> > '/slide/files')
> > DAV:all
> > granted to property (not protected) (inherited from
'/slide/files')
> > DAV:read-acl
> > granted to /slide/roles/root (not protected) (inherited
from
> > '/slide/')
> > DAV:all
> > denied to all (not protected) (inherited from '/slide/')
> > DAV:read-acl
> > DAV:write-acl
> > DAV:unlock
> > granted to /slide/roles/user (not protected) (inherited
from
> > '/slide/')
> > DAV:read
> > ------------------------------------------------------------
> >
> > Any ideas of how can i configure the right acls ?
> >
> > thanx in advance
> > Carlos
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > IMPORTANT NOTICE
> > If you have received this e-mail in error or wish to read our
e-mail
> > disclaimer statement and monitoring policy, please refer to
the
> > statement below or contact the sender. This communication is
from
> > Deloitte & Touche LLP. Deloitte & Touche LLP is a limited
liability
> > partnership registered in England and Wales with registered
number
> > OC303675. A list of members' names is available for
inspection at
> > Stonecutter Court, 1 Stonecutter Street, London EC4A 4TR,
United
> > Kingdom, the firm's principal place of business and
registered office.
> > Deloitte & Touche LLP is authorised and regulated by the
Financial
> > Services Authority. This communication and any attachments
contain
> > information which is confidential and may also be privileged.
It is
> > for the exclusive use of the intended recipient(s). If you
are not the
> > intended recipient(s) please note that any form of disclosure,
> > distribution, copying or use of this communication or the
information in
> > it or in any attachments is strictly prohibited and may be
unlawful. If
> > you have received this communication in error, please return
it with the
> > title "received in error" to [EMAIL PROTECTED] then delete
> > the email and destroy any copies of it. E-mail communications
cannot be
> > guaranteed to be secure or error free, as information could be
> > intercepted, corrupted, amended, lost, destroyed, arrive late
or
> > incomplete, or contain viruses. We do not accept liability
for any such
> > matters or their consequences. Anyone who communicates with
us by
> > e-mail is taken to accept the risks in doing so. When
addressed to our
> > clients, any opinions or advice contained in this e-mail and
any
> > attachments are subject to the terms and conditions expressed
in the
> > governing Deloitte & Touche LLP client engagement letter.
Opinions,
> > conclusions and other information in this e-mail and any
attachments
> > which do not relate to the official business of the firm are
neither
> > given nor endorsed by it.
> >
> >
---------------------------------------------------------------------
> > 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
IMPORTANT NOTICE
If you have received this e-mail in error or wish to read our e-mail disclaimer
statement and monitoring policy, please refer to the statement below or contact
the sender.
This communication is from Deloitte & Touche LLP. Deloitte & Touche LLP is a
limited liability partnership registered in England and Wales with registered
number OC303675. A list of members' names is available for inspection at
Stonecutter Court, 1 Stonecutter Street, London EC4A 4TR, United Kingdom, the
firm's principal place of business and registered office. Deloitte & Touche
LLP is authorised and regulated by the Financial Services Authority.
This communication and any attachments contain information which is
confidential and may also be privileged. It is for the exclusive use of the
intended recipient(s). If you are not the intended recipient(s) please note
that any form of disclosure, distribution, copying or use of this communication
or the information in it or in any attachments is strictly prohibited and may
be unlawful. If you have received this communication in error, please return
it with the title "received in error" to [EMAIL PROTECTED] then delete the
email and destroy any copies of it.
E-mail communications cannot be guaranteed to be secure or error free, as
information could be intercepted, corrupted, amended, lost, destroyed, arrive
late or incomplete, or contain viruses. We do not accept liability for any
such matters or their consequences. Anyone who communicates with us by e-mail
is taken to accept the risks in doing so.
When addressed to our clients, any opinions or advice contained in this e-mail
and any attachments are subject to the terms and conditions expressed in the
governing Deloitte & Touche LLP client engagement letter.
Opinions, conclusions and other information in this e-mail and any attachments
which do not relate to the official business of the firm are neither given nor
endorsed by it.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
