Bill
> From: Justin Erenkrantz [mailto:jerenkrantz@apache.org]
>
> On Thu, Aug 22, 2002 at 12:41:12AM -0700, Bill Tutt wrote:
> > Commentary on entire proposal:
> > Trying to mesh Subversion ACL behavior into OS specific and indeed
WC
> > specific visible behavior just seems wrong. Subversion's ACL system
> > should be about securing SCM operations not defining the assigned
ACEs
> > of the generated files in the working copy.
>
> My question back to you is why shouldn't it? If I can't modify
> the file on the repository, why should I (by default) be able to
> modify the file locally?
>
> (Yes, this is about smashing preconceptions here. We could provide
> an opt-out in the client config if they wanted to set everything to
> APR_OS_DEFAULT rather than intelligently setting the attributes. Or,
> make it opt-in - I don't care.)
>
That's the simple case. Please don't use a simple read-only example to
justify the amount of features you're proposing.
I think if you're going to do something, you should do it well. Given
that ACL-able actions vary on an operating system, and filesystem basis,
it becomes impossible for Subversion to do anything in this space well.
I will agree that WC copies should be marked read-only if the user
doesn't have the security rights to change them. However, that has
nothing to do with whatever permissions you want the WC copy of the file
to have, it has to do with the SCM ACL model. You might want the WC copy
of the file to be writable, but since the user can't modify the file,
the WC copy is now read-only. How utterly confusing to the poor user.
The WC copy should either transparently reflect the permissions desired,
or it should reflect semantics that are useful for the communication of
the SCM's ACL model to the user.
This line of reasoning and the necessity to mark files read-only in the
WC copy due to server side locking issues in the future makes me very
averse to trying to recreate desired permissions in the working copy.
> > Additionally, naively searching an list of ACEs for denying ACE, and
> > then searching for allowing ACEs doesn't actually happens. The ACEs
are
> > applied exactly in order.
>
> Right. As was pointed out in several lists, that seemed to be a flaw
> in NT's security model. I wouldn't need to see that 'feature'
> replicated in SVN if we implemented ACLs.
>
I disagree actually. Specific orderings allow completely different
behavior patterns as evidenced by the ordering preferred by Win2k+.
The Win2k+ behavior has all non-inherited ACEs ordered before inherited
ACEs regardless of their deny/allow behavior.
[...]
> > Ick. See what I mean by complicated? If we were to define ACEs for
> > Subversion there would be a bunch more possible operations anyway.
> >
> > e.g.:
> > Subversion_LogMessage_Change
> > Etc...
>
> Do we really need or want this level of specificity? Hmm.
> Subversion's log doesn't quite fit anywhere, so perhaps, that gets a
> repository-wide ACE? (Doesn't seem that DeltaV ACL has this
> concept.)
>
Yes, we do. How deep down that rat hole we need to go is still up for
discussion I think, but yes. There will be several repository wide
operations that need to be able to have an ACL set for them. (In a
Subversion that has ACLs.) There are very good reasons why most
operating systems have ACEs that are for specific purposes. i.e.
backup/restore, etc..
> > > +Question: How do we define groups since they are server-side?
> > > + (Must define the group somewhere - perhaps walk up tree
at
> > each
> > > + directory looking for a group definition mechanism.)
> > Ick. We don't walk up directory trees. :)
>
> As I said somewhere later on, maybe not.
>
> But, it looks like this is how DAV:group-membership is defined
> (indirect reference). -- Justin
The WebDAV ACL spec doesn't define much of anything on how group
membership is interpreted anywhere but the server. You can't propagate
groups to the client. It's just not feasible, portable, or necessarily
desirable.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 22 20:43:45 2002