Proposal: mod_authz_svn to get an option to inform clients that resource 'cannot be written to'

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Proposal: mod_authz_svn to get an option to inform clients that resource 'cannot be written to'

Paul Hammant-3
For my file-sync tech, I want to flip readonly bits within the filesystem when I Curl-GET resources down from Svn. While mod_authz_svn adjudicates on where a) resources are readable by the user in question and b) whether writable. 

If an item were readable, but not writable, the only way the end-user would know that is in an attempt to commit (regular Svn client), or PUT (SVNAutoversioning on). It's vetoed then.

I'm not advocating the changing of the Subversion client's default behavior, but it would be great for the information about writability for that user were passed to the client as part of the retrieval of the resource.

Specifically, I am advocating for a new response HTTP header to be added. There's no standard header for 'this resource is read-only'. Probably because the original intent of the web was that everything was read-only and write only came with DAV (HTTP 1.1; Greg Stein and a committee). Anyway, I'm proposing that mod_authz_svn adds a header as the resource is sent to the client.

My sync agent will flip the read-only bits on the client copy, and continue to sync the resource from Svn if it changes and as expected (also noting if it becomes writable for that user later on).

Secondarily, I would expect Subversion's client to gain a new option:

    --make-workingcopy-resources-readonly-if-applicable

Thoughts?

After a conversation here, I'd like to raise a feature request in Jira for this. I understand this conversation to be a pre-requisite to that.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: mod_authz_svn to get an option to inform clients that resource 'cannot be written to'

Paul Hammant-3
So maybe the header added to HTTP GETs of resources would be:

    resource-is-not-modifiable-by-you: true

In the absence of this new feature of Subversion

I'm going to have to encode something verbose in the repo itself as hidden files:

    <repo-URL>/.sync/server-settings/users/<username>/readonly-masks.txt

And I would generate those masks from dav_svn.authz for that user (on the server side). The file would be Globbing/regex-ish, of course. 

Regards,

- Paul
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: mod_authz_svn to get an option to inform clients that resource 'cannot be written to'

bahrep
Hello,

What is the story? How is this going to help Subversion users?

The idea sounds interesting. However, I'm not sure how it will help
the users. I don't mind whether I have Read Only or Read / Write
access to an FTP resource or another kind of remote data. I just know
whether I have access to the resource or not. IMO, this is a
communication problem and it's not what SVN has to solve.

On Wed, Jul 19, 2017 at 6:25 PM, Paul Hammant <[hidden email]> wrote:

> So maybe the header added to HTTP GETs of resources would be:
>
>     resource-is-not-modifiable-by-you: true
>
> In the absence of this new feature of Subversion
>
> I'm going to have to encode something verbose in the repo itself as hidden
> files:
>
>     <repo-URL>/.sync/server-settings/users/<username>/readonly-masks.txt
>
> And I would generate those masks from dav_svn.authz for that user (on the
> server side). The file would be Globbing/regex-ish, of course.
>
> Regards,
>
> - Paul



--
With best regards,
Pavel Lyalyakin
VisualSVN Team
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: mod_authz_svn to get an option to inform clients that resource 'cannot be written to'

Paul Hammant-3

What is the story? How is this going to help Subversion users?

The idea sounds interesting. However, I'm not sure how it will help
the users. I don't mind whether I have Read Only or Read / Write
access to an FTP resource or another kind of remote data. I just know
whether I have access to the resource or not. IMO, this is a
communication problem and it's not what SVN has to solve.
 
It will help the owners of subversion repos preventing files from being overwritten that they do not want to be overwritten. e.g. Company's Word template (.DOT files).

It will help subversion end-users not upset the owners of repositories by changing files (and committing them back) that there are not supposed to.

Sure, it's only read-only bit and can be flipped by anyone who can launch WindowsExplorer and pop a properties tab for the file, etc.  That's worth mentioning because the time honored provision of corporate files over a network share comes with an ability to lock the read-only bit for files. That said the end user could copy those files to their C: drive.

- Paul
 
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: mod_authz_svn to get an option to inform clients that resource 'cannot be written to'

Branko Čibej
On 21.07.2017 11:00, Paul Hammant wrote:

>
>
>     What is the story? How is this going to help Subversion users?
>
>     The idea sounds interesting. However, I'm not sure how it will help
>     the users. I don't mind whether I have Read Only or Read / Write
>     access to an FTP resource or another kind of remote data. I just know
>     whether I have access to the resource or not. IMO, this is a
>     communication problem and it's not what SVN has to solve.
>
>  
> It will help the owners of subversion repos preventing files from
> being overwritten that they do not want to be overwritten. e.g.
> Company's Word template (.DOT files).

Use the svn:needs-lock property.

> It will help subversion end-users not upset the owners of repositories
> by changing files (and committing them back) that there are not
> supposed to.

Use access control.

-- Brane

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: mod_authz_svn to get an option to inform clients that resource 'cannot be written to'

Julian Foad-4
In reply to this post by Paul Hammant-3
Paul Hammant wrote:> It will help the owners of subversion repos
preventing files from being> overwritten that they do not want to be
overwritten. [...]
>
> It will help subversion end-users not upset the owners of repositories
> by changing files (and committing them back) that there are not
supposed to.

I kind of like your suggestion in general terms -- because a polite
system ought to inform the user what they can and cannot do, before they
waste time trying it -- but I don't understand your reply here.

In your original message you wrote "mod_authz_svn adjudicates". These
authz rules are strict: a user cannot override them from their side.

> Secondarily, I would expect Subversion's client to gain a new option:
>
>     --make-workingcopy-resources-readonly-if-applicable

The "svn:needs-lock" property for "advisory locking" causes the
Subversion client to make files read-only in the WC when the user
doesn't have the corresponding lock. See
<http://svnbook.red-bean.com/nightly/en/svn.advanced.locking.html>. A
user can override ("break") this kind of lock if they want to.

That mechanism is usually used for files for which the user, or *some*
users, have write access. I suppose files which are authz-read-only for
the current user, could also be marked read-only in the WC regardless of
whether they have svn:needs-lock. That sounds reasonable to me so far.

> Sure, it's only read-only bit and can be flipped by anyone who can
> launch WindowsExplorer and pop a properties tab for the file, etc.
> That's worth mentioning because the time honored provision of corporate
> files over a network share comes with an ability to lock the read-only
> bit for files. That said the end user could copy those files to their C:
> drive.

That's all fine -- users can and should do whatever they want or need to
with their local files.

- Julian

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: mod_authz_svn to get an option to inform clients that resource 'cannot be written to'

Paul Hammant-3
May I go ahead and raise the feature request in Jira now?

I believe the approved process was discuss on mail-list, then raise in Jira.

- Paul

On Fri, Jul 21, 2017 at 5:40 AM, Julian Foad <[hidden email]> wrote:
Paul Hammant wrote:> It will help the owners of subversion repos
preventing files from being> overwritten that they do not want to be
overwritten. [...]
>
> It will help subversion end-users not upset the owners of repositories
> by changing files (and committing them back) that there are not
supposed to.

I kind of like your suggestion in general terms -- because a polite
system ought to inform the user what they can and cannot do, before they
waste time trying it -- but I don't understand your reply here.

In your original message you wrote "mod_authz_svn adjudicates". These
authz rules are strict: a user cannot override them from their side.

> Secondarily, I would expect Subversion's client to gain a new option:
>
>     --make-workingcopy-resources-readonly-if-applicable

The "svn:needs-lock" property for "advisory locking" causes the
Subversion client to make files read-only in the WC when the user
doesn't have the corresponding lock. See
<http://svnbook.red-bean.com/nightly/en/svn.advanced.locking.html>. A
user can override ("break") this kind of lock if they want to.

That mechanism is usually used for files for which the user, or *some*
users, have write access. I suppose files which are authz-read-only for
the current user, could also be marked read-only in the WC regardless of
whether they have svn:needs-lock. That sounds reasonable to me so far.

> Sure, it's only read-only bit and can be flipped by anyone who can
> launch WindowsExplorer and pop a properties tab for the file, etc.
> That's worth mentioning because the time honored provision of corporate
> files over a network share comes with an ability to lock the read-only
> bit for files. That said the end user could copy those files to their C:
> drive.

That's all fine -- users can and should do whatever they want or need to
with their local files.

- Julian


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: mod_authz_svn to get an option to inform clients that resource 'cannot be written to'

Julian Foad-5
Paul Hammant wrote:
> May I go ahead and raise the feature request in Jira now?

Thanks for discussing here so far. Yes you may file it.

In order for it to progress to acceptance you probably also need to
clarify and finish discussing. It sounds like you have a clear idea of
what you want but it's not quite so clear to me. I'm not at all close to
the server side, especially client-less use cases, so I might well miss
the bigger picture.

For example, in my reply that you quoted below, I suggested your
rationale didn't make sense and suggested instead my own rationale that
"a polite system ought to inform the user what they can and cannot do"
-- in other words it's about helping the users not the admins.

Also how does this relate to authenticated read access vs.
unauthenticated (anonymous) read access? Could some useful indicator be
given even in the anonymous case?

Your thoughts please?

- Julian


> I believe the approved process was discuss on mail-list, then raise in Jira.
>
> - Paul
>
> On Fri, Jul 21, 2017 at 5:40 AM, Julian Foad <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Paul Hammant wrote:> It will help the owners of subversion repos
>     preventing files from being> overwritten that they do not want to be
>     overwritten. [...]
>     >
>     > It will help subversion end-users not upset the owners of repositories
>     > by changing files (and committing them back) that there are not
>     supposed to.
>
>     I kind of like your suggestion in general terms -- because a polite
>     system ought to inform the user what they can and cannot do, before they
>     waste time trying it -- but I don't understand your reply here.
>
>     In your original message you wrote "mod_authz_svn adjudicates". These
>     authz rules are strict: a user cannot override them from their side.
>
>     > Secondarily, I would expect Subversion's client to gain a new option:
>     >
>     >     --make-workingcopy-resources-readonly-if-applicable
>
>     The "svn:needs-lock" property for "advisory locking" causes the
>     Subversion client to make files read-only in the WC when the user
>     doesn't have the corresponding lock. See
>     <http://svnbook.red-bean.com/nightly/en/svn.advanced.locking.html
>     <http://svnbook.red-bean.com/nightly/en/svn.advanced.locking.html>>. A
>     user can override ("break") this kind of lock if they want to.
>
>     That mechanism is usually used for files for which the user, or *some*
>     users, have write access. I suppose files which are authz-read-only for
>     the current user, could also be marked read-only in the WC regardless of
>     whether they have svn:needs-lock. That sounds reasonable to me so far.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: mod_authz_svn to get an option to inform clients that resource 'cannot be written to'

Paul Hammant-3
You are 100% correct.

For an anon svn-co (if allowed by the server), the default behavior should be as is now - making working copy that is editable.
For an anon svn-co (if allowed by the server), the behavior if a new option is specified - make the files readonly (Win and Unix derivatives)

For authenticated svn-co, the default behavior should be as is now - making working copy that is editable.
For authenticated svn-co, tthe behavior if a new option is specified - make the files readonly (Win and Unix derivatives)

That new option (on the CLI at least), would be one of --percolate-readonly-attr --make-files-readonly-if-applicable --RO-bit-too --only-writable-in-wc-if-writable-on-server-for-this-user-argghhh-this-is-a-bit-long :)

I would Imagie Subversion would always impart the attr for each file to the client, but the client only acts on it if 

1. the right CLI option was specified
1.1 per command?
2. specified in the original checkout and remembered going forwards
3. subject to some policy on the server
4. subject to some --global policy

And yes, the Jira posting would need to be a distillation of all of the rolled up thought and common wisdom on this thread and its contributors :)

Regards,

- Paul


- Paul

On Tue, Jul 25, 2017 at 11:38 AM, Julian Foad <[hidden email]> wrote:
Paul Hammant wrote:
> May I go ahead and raise the feature request in Jira now?

Thanks for discussing here so far. Yes you may file it.

In order for it to progress to acceptance you probably also need to
clarify and finish discussing. It sounds like you have a clear idea of
what you want but it's not quite so clear to me. I'm not at all close to
the server side, especially client-less use cases, so I might well miss
the bigger picture.

For example, in my reply that you quoted below, I suggested your
rationale didn't make sense and suggested instead my own rationale that
"a polite system ought to inform the user what they can and cannot do"
-- in other words it's about helping the users not the admins.

Also how does this relate to authenticated read access vs.
unauthenticated (anonymous) read access? Could some useful indicator be
given even in the anonymous case?

Your thoughts please?

- Julian


> I believe the approved process was discuss on mail-list, then raise in Jira.
>
> - Paul
>
> On Fri, Jul 21, 2017 at 5:40 AM, Julian Foad <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Paul Hammant wrote:> It will help the owners of subversion repos
>     preventing files from being> overwritten that they do not want to be
>     overwritten. [...]
>     >
>     > It will help subversion end-users not upset the owners of repositories
>     > by changing files (and committing them back) that there are not
>     supposed to.
>
>     I kind of like your suggestion in general terms -- because a polite
>     system ought to inform the user what they can and cannot do, before they
>     waste time trying it -- but I don't understand your reply here.
>
>     In your original message you wrote "mod_authz_svn adjudicates". These
>     authz rules are strict: a user cannot override them from their side.
>
>     > Secondarily, I would expect Subversion's client to gain a new option:
>     >
>     >     --make-workingcopy-resources-readonly-if-applicable
>
>     The "svn:needs-lock" property for "advisory locking" causes the
>     Subversion client to make files read-only in the WC when the user
>     doesn't have the corresponding lock. See
>     <http://svnbook.red-bean.com/nightly/en/svn.advanced.locking.html
>     <http://svnbook.red-bean.com/nightly/en/svn.advanced.locking.html>>. A
>     user can override ("break") this kind of lock if they want to.
>
>     That mechanism is usually used for files for which the user, or *some*
>     users, have write access. I suppose files which are authz-read-only for
>     the current user, could also be marked read-only in the WC regardless of
>     whether they have svn:needs-lock. That sounds reasonable to me so far.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: mod_authz_svn to get an option to inform clients that resource 'cannot be written to'

Paul Hammant-3

I've tried to focus on the meat of the ask, and cover previous questions. Also I've covered previous suggestions, though while welcome, would not solve the same problem. 
Loading...