[DESIGN] File Permissions Preservation

["Gale, David" <Da...@Hypertherm.com>]

Inspired by the ongoing '[DESIGN] mtime versioning - was: Getting Bug
1256 fixed' thread, I'd like to put forth the following, mainly because
it's mentioned in passing in bug 1256, and not (as far as I can tell) in
any other bug in the issue tracker.

Requirement: Preserve file permissions on checkout.

Intention: An expansion of the functionality currently provided by the
svn:executable property, to allow files to retain the exact permissions
they're committed with.  Some files need to be read-only for certain
processes to work, some need to be globally editable, some need to have
the sticky bit set, etc.

Terminology: Since permissions apply to files and directories, I will
henceforth use 'file' to refer to both unless specifically indicated
otherwise.

Details:
 - NOTE: UNIX and Linux files have a fairly wide range of permissions
possibilities.  Windows is more limited (something is read-only or it
isn't; there is no executable flag that I'm aware of).  I don't know
about Macintosh permissions; perhaps someone else can speak to this.
 1) On commit, each file's permissions should be stored.
 2) On checkout, the file should be set to match the stored permissions.
  a) If checking out to a system (such as Windows) that doesn't support
the full set of permissions, any non-applicable permissions should be
ignored.  (Thus, a read-only file remains read-only, even if there is no
executable bit).
  b) These ignored permissions should still be "present" and, ideally,
editable by the user, so as to not break permissions when developing
cross-system.
 3) svn status and svn update should recognize changed permissions as a
change to the file, and respond accordingly.
 4) If a user doesn't have the ability to set permissions, a warning
should be issued & the file created according to the user's umask.
 5) The only issue I can think of is with svn:needs-lock, since it
overrides the standard permissions processes.  I would propose having
svn:needs-lock continue to function as current (toggling between the
"official" permissions as stored in the file permissions property and a
read-only equivalent), with a special override flag to svn update and
svn checkout to allow checking out to/updating a production system
without svn:needs-lock automatically making the file read-only.

My best thought for the actual "how" of the implementation would be as a
property, as that automatically fulfils points 1, 2b, and 3.

Note that this would deprecate svn:executable.

Comments?

-David

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: [DESIGN] File Permissions Preservation

[Gary Feldman <sv...@marsdome.com>]

Gale, David wrote:
...
>  1) On commit, each file's permissions should be stored.
>  2) On checkout, the file should be set to match the stored permissions.
...
>  3) svn status and svn update should recognize changed permissions as a
> change to the file, and respond accordingly.

ACLs aside, I don't really like the idea of doing an implicit permissions change 
upon a commit.  In my experience, it's common for files in working copies to 
have their permissions changed without intending a change to the version in the 
repository.  Various editors don't always preserve permissions, users may want 
to feed their program through a pretty printer first, and the permissions for 
development may be totally unrelated to the permissions for deployment. 
Conversely, it's not very common to want to change the permissions as far as the 
repository is concerned, and hence it's ok if it takes a bit of work.

ACLs make things worse.  (OK, I lied about setting them aside.)  In Windows (and 
imagine most other ACL systems, ACLs can be inherited from parent directories. 
So users Pat and Leslie who are pair programming may have their working copy set 
to allow both of them to edit the files (i.e. an ACL that explicitly contains 
their names), while others just rely on owner permissions.  Do you change 
permissions every time it gets checked in, based on the inherited permissions? 
I think not.  On the other hand, if someone is adding a brand new file, it may 
not have any of its own permissions; they're frequently all inherited.  And so on.

I think it makes more sense just to have explicit actions to change permissions 
as far as the repository is concerned.  In theory, one could set permissions via 
properties, and have something to parse and set them upon checkout.  One could 
even have platform-specific permissions (e.g. svn::perm::unix and 
svn::perm::windows).  The content could be in formats convenient for the given 
platform, so that the native commands could be used to import and export them. 
This could even be taken a step further, by having plug-ins to cope with 
additional platforms (e.g. Apache permissions).  If and when client-side 
triggers become reality, that might be an ideal way to implement this mechanism, 
or at least prototype it.

>  4) If a user doesn't have the ability to set permissions, a warning
> should be issued & the file created according to the user's umask.

Do you mean in the repository or the working copy?  I'm not familiar with any 
way a user couldn't have the ability to change permissions on a file he created, 
so I don't understand this point.

Gary


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: [DESIGN] File Permissions Preservation

[Garrett Rooney <ro...@electricjellyfish.net>]

On 12/22/05, Ryan Schmidt <su...@ryandesign.com> wrote:

> I understand that ACLs are, or are trying to become, the cross-
> platform permissioning solution. According to the Wikipedia, they're
> available on Windows, Mac OS X, Linux, *BSD, Solaris and OpenVMS, and
> are a POSIX standard.
>
> http://en.wikipedia.org/wiki/Access_control_list

They're "available" on all these platforms, but the actual effect of a
given ACL differs wildly between them.  We had some brief
conversations about how to implement support for ACLs in APR at
ApacheCon this year, and the differences between how the different
systems treat them makes it a really hard problem.

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: [DESIGN] File Permissions Preservation

[Ryan Schmidt <su...@ryandesign.com>]

Sorry I'm late to this discussion...


> On 11/28/05, Gale, David <Da...@hypertherm.com> wrote:
>
>>  - NOTE: UNIX and Linux files have a fairly wide range of permissions
>> possibilities.  Windows is more limited (something is read-only or it
>> isn't; there is no executable flag that I'm aware of).  I don't know
>> about Macintosh permissions; perhaps someone else can speak to this.

Subversion does not work on Classic Mac OS, so that can be forgotten.  
And Mac OS X is a Unix-like operating system and can be thought of as  
such.


On Nov 28, 2005, at 20:38, Garrett Rooney wrote:

> Actually, you're wrong, Windows has a much finer grained permissioning
> system than Unix, and many things it can express simply cannot be done
> with simple unix users and groups.  Similarly, many unix systems have
> more fine grained permissioning available than the traditional
> users/groups thing, but there's no real standard for it that is
> generally available.
>
> The main problem we've always run into when trying to do this is
> simply that permissioning is not a cross platform concept, and we
> generally try to avoid features that will only work on a certain
> platform.

I understand that ACLs are, or are trying to become, the cross- 
platform permissioning solution. According to the Wikipedia, they're  
available on Windows, Mac OS X, Linux, *BSD, Solaris and OpenVMS, and  
are a POSIX standard.

http://en.wikipedia.org/wiki/Access_control_list



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: [DESIGN] File Permissions Preservation

[Garrett Rooney <ro...@electricjellyfish.net>]

On 11/28/05, Gale, David <Da...@hypertherm.com> wrote:

>  - NOTE: UNIX and Linux files have a fairly wide range of permissions
> possibilities.  Windows is more limited (something is read-only or it
> isn't; there is no executable flag that I'm aware of).  I don't know
> about Macintosh permissions; perhaps someone else can speak to this.

Actually, you're wrong, Windows has a much finer grained permissioning
system than Unix, and many things it can express simply cannot be done
with simple unix users and groups.  Similarly, many unix systems have
more fine grained permissioning available than the traditional
users/groups thing, but there's no real standard for it that is
generally available.

The main problem we've always run into when trying to do this is
simply that permissioning is not a cross platform concept, and we
generally try to avoid features that will only work on a certain
platform.

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org