You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by David Myers <da...@gmail.com> on 2011/07/16 22:14:25 UTC
Can I prevent a file from being modified?
Dear subversion,
I have recently started a new post and I am in the process of
investigating some possible new working practices. This particularly
relates to document control.
I have read in various places about the 'tagging' system (where by I can
use a property to effectively 'name' a file) used by subversion and
things such as svn:needs-lock that forces any user who tries to commit a
change to a file to be asked to acquire the lock that the file holds.
These almost fit my requirements, but not quite.
What I require is a method where I can make the file truly 'read only'
after a certain point.
From what I have read in various places I thing I understand that...
subversion reflects the unix style permissions on it's subdirectories,
in the subversion directory tree.
If I want to make a specific location 'read only' I need to do this from
a new directory, and then files in this directory will acquire the
permissions of the parent directory.
subversion doesn't store the file permissions of a file directly it
stores it within the svn:properties
However if the above statement is correct this may not fill my requirements.
Let me expand on my problem (situation).
A group of users may be working on a file over time. At a certain point
they all agree that the file is up to its required needs and they
formally create a hard copy of this file, and store it as a controlled
document (signed and counter signed blah blah blah).
The finalised hard copy of the file must be an exact match of the copy
stored electronically. All the users will be aware that this file
shouldn't be change on the disk. But life being life when a user opens
the file to print it they may inadvertently add a space in a paragraph,
or an accidental carriage return, or worse
how often have you been working on document1 when you get that
phone call to ask about a specific part of the controlled document2,
so you open the document to have a quick read and clarify the
situation. Then you get distracted by something else and you return
and start editing the document2, thinking you are editing document1.
We all know it shouldn't happen but it does occasionally.
What I want to be sure of is that even if this is done by accident there
is no way that the file on disk in the subversion repository can be
inadvertently changed. The svn:need-lock property combined with another
personal property (something along the lines of CtrlDoc:DO_NOT_CHANGE
TRUE ), unless there is an svn:read-only property that I am yet to come
across!
I feel that the combination of these properties and proper use of the
Head, commit and branch strategies should enable myself and my users to
ensure that these types of problems don't occur.
Please help me clarify this so as I can propose the use of a subversion
to my colleagues, and give eloquent and correct answers to any of their
queries.
Thanks in advance.
David
--
Tel: + 33 6 50 14 39 34
email:
david.myers.24j74@gmail.com
Adresse:
56 Rue du Coteau du Parc,
91180 Saint Germain les Arpajon
Re: Can I prevent a file from being modified?
Posted by Les Mikesell <le...@gmail.com>.
On 7/22/2011 11:36 AM, David Weintraub wrote:
>
> This allows you to add in directories directly under the "tags"
> directory via an "svn cp", but you can't add anything under those
> directories.
>
> I don't make a distinction between files, and directories. It is
> possible to use "svn add" to add in empty directories and files
> directly under the /tags directory, so it's not entirely secure from
> maliciousness. However, it really wouldn't do anything more than be
> annoying and since this is version control, the culprit could easily
> be caught.
Yes, the revision control part is always there. While we tend to use
tags to get simple human-generated, human-readable names for specific
revisions (through the convention of never committing changes there),
all you really have to do to be sure you have a particular version is
use the path@revision syntax in your workflow. It is impossible for
that to ever be changed through subversion client operations.
--
Les Mikesell
lesmikesell@gmail.com
Re: Can I prevent a file from being modified?
Posted by David Weintraub <qa...@gmail.com>.
On Thu, Jul 21, 2011 at 12:47 PM, Andreas Krey <a....@gmx.de> wrote:
> On Thu, 21 Jul 2011 11:06:00 +0000, David Weintraub wrote:
>> I have a pre-commit hook that allows you to set a directory as
>> "add-only". This was mainly for the tags directory. You can create a
>> tag, but once created, it can't be modified.
>
> The devil's advocate wants to know it this script accidentally also
> allows adding new files/directories *within* a tag; thus getting
> interesting results when accidentally executing
>
> svn cp $base/trunk $base/tags/blub -m "$message"
It all depends how you configure the control file. If you simply did
something like this:
file = /tags/**
user = @ALL
access = add-only
Then, it would be possible for someone to add a directory inside
another directory under the tags directory.
I haven't worried about this. My main concern isn't someone doing
something malicious, but doing something more human. For example, a
developer did a "svn switch" to a tag to see the files on a particular
revision, then promptly forgot they did the switch and edit that
working directory. No clue would be given that they were not on trunk
or a branch while doing their work, and they may simply not realize it
even after a commit.
However, if you want to prevent maliciousness, you first lock down the
directories under tags:
[FILE No modifying anything under /tags]
file = /tags/**
user = @ALL
access = read-only
This prevents any changes at all under the /tags directory.
Now, you add in the following:
[FILE Allow users to add new tags, but that's all]
file = /tags/*
user = @ALL
access = add-only
This allows you to add in directories directly under the "tags"
directory via an "svn cp", but you can't add anything under those
directories.
I don't make a distinction between files, and directories. It is
possible to use "svn add" to add in empty directories and files
directly under the /tags directory, so it's not entirely secure from
maliciousness. However, it really wouldn't do anything more than be
annoying and since this is version control, the culprit could easily
be caught.
--
David Weintraub
qazwart@gmail.com
Re: Can I prevent a file from being modified?
Posted by Andreas Krey <a....@gmx.de>.
On Thu, 21 Jul 2011 11:06:00 +0000, David Weintraub wrote:
> I have a pre-commit hook that allows you to set a directory as
> "add-only". This was mainly for the tags directory. You can create a
> tag, but once created, it can't be modified.
The devil's advocate wants to know it this script accidentally also
allows adding new files/directories *within* a tag; thus getting
interesting results when accidentally executing
svn cp $base/trunk $base/tags/blub -m "$message"
twice (a directory named trunk within the tag).
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Can I prevent a file from being modified?
Posted by David Weintraub <qa...@gmail.com>.
I have a pre-commit hook that allows you to set a directory as
"add-only". This was mainly for the tags directory. You can create a
tag, but once created, it can't be modified.
This should fit well in your process. You can give it a try. I've just
done a major rewrite that is more object oriented and allows you to
use LDAP groups for file permissioning. However, this link is to the
old tried and true version.
<http://db.tt/H3o1i7S>
You'll need Perl on your Subversion repository server to run this, but
you shouldn't need any optional CPAN modules.
--
David Weintraub
qazwart@gmail.com
AW: Can I prevent a file from being modified?
Posted by Markus Schaber <m....@3s-software.com>.
Hi,
Von: Markus Schaber [mailto:m.schaber@3s-software.com]
> Von: David Myers [mailto:david.myers.24j74@gmail.com]
> > What I require is a method where I can make the file truly 'read
only'
> after a certain point.
>
> My suggestion is a special property you invent yourself (like
> FileFrozenReadonly), and a post-commit hook which prevents commits on
all
> files having that property set. You may even combine it with the
> svn:needs-lock property which makes SVN check out the files as
read-only.
Of course, I meant a pre-commit hook - a post-commit hook cannot prevent
the commit by concept. :-)
You could also combine that with the needs-lock property and a pre-lock
hook which prevents getting the lock on those files.
More information can be found at
http://svnbook.red-bean.com/nightly/en/svn.reposadmin.create.html.
Best regards
Markus Schaber
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 |
Fax +49-831-54031-50
Email: m.schaber@3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects:
http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner |
Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: Can I prevent a file from being modified?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Jul 19, 2011, at 06:23, david myers wrote:
> Also the file is stored on disk somehow, so I thought I may be able to directly manipulate the access permissions on a directory / file, I just wanted to know if this would work or not. From what I read I understood that this was the case, if however SVN silently 'ignores' these types of permission that is fair enough, I guess the process runs as a super user, which would make sense (most server processes seem to want to have full power over their own process, which seems reasonable).
That's not possible because a Subversion repository is a database; there is not a one-to-one mapping between a file or directory in a repository and a file or directory on your server's hard disk.
Re: Can I prevent a file from being modified?
Posted by david myers <da...@gmail.com>.
Hi all,
Wow, lots of good thoughts.
@Chris
I like the MD5 idea, I hadn't thought of that but it makes sense.
@Ryan
when I said "svn:properties" I was thinking of things like svn:needs-lock
and svn:executable, from the manual (chapter 3)
In addition to versioning your directories and files, Subversion provides
interfaces for adding, modifying, and removing versioned metadata on each of
your versioned directories and files. We refer to this metadata as *
properties*..
I was in fact wondering if there was a way to make a custom property that
would cause a file to be truly 'locked', as suggested by Markus.
Also the file is stored on disk somehow, so I thought I may be able to
directly manipulate the access permissions on a directory / file, I just
wanted to know if this would work or not. From what I read I understood that
this was the case, if however SVN silently 'ignores' these types of
permission that is fair enough, I guess the process runs as a super user,
which would make sense (most server processes seem to want to have full
power over their own process, which seems reasonable).
@Daniel
thanks for the idea of the wrapper scripts
@Markus
Thanks, I had thought of a custom property already, but I hadn't read
anything on ' post-commit hook', so I'm off for another look at the manual
and trawl through google.
Maybe if I can use a post commit hook linked to the files MD5 checksum...
And of course if there any any changes made I will always be able to return
to the 'correct' version
Thanks again all.
David
ps. the first time I responded I hit reply, so it didn't go to the list,
thanks to Markus for pointing that one out. And apologies to Markus as he is
now receiving this mail a second time!
On Tue, Jul 19, 2011 at 10:53 AM, Markus Schaber
<m....@3s-software.com>wrote:
> Hi, David,****
>
> ** **
>
> Was it intentional that you did send this answer just to me? Maybe you
> should reply to the list instead. J****
>
> ** **
>
> Best regards
>
> Markus Schaber
>
> ___________________________****
>
> We software Automation.
>
> 3S-Smart Software Solutions GmbH
> Markus Schaber | Developer
> Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax
> +49-831-54031-50
>
> Email: *m.schaber@3s-software.com* | Web: http://www.3s-software.com
> CoDeSys internet forum: http://forum.3s-software.com<http://forum-en.3s-software.com>
> Download CoDeSys sample projects:
> http://www.3s-software.com/index.shtml?sample_projects
>
> *Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner* | *Trade
> register: Kempten HRB 6186* | *Tax ID No.: DE 167014915** *****
>
> ** **
>
> *Von:* david myers [mailto:david.myers.24j74@gmail.com]
> *Gesendet:* Dienstag, 19. Juli 2011 09:43
> *An:* Markus Schaber
> *Betreff:* Re: Can I prevent a file from being modified?****
>
> ** **
>
> Hi all,
>
> Wow, lots of good thoughts.
>
> @Chris
> I like the MD5 idea, I hadn't thought of that but it makes sense.
>
> @Ryan
> when I said "svn:properties" I was thinking of things like svn:needs-lock
> and svn:executable, from the manual (chapter 3)****
>
>
> In addition to versioning your directories and files, Subversion provides
> interfaces for adding, modifying, and removing versioned metadata on each of
> your versioned directories and files. We refer to this metadata as *
> properties*..****
>
>
> I was in fact wondering if there was a way to make a custom property that
> would cause a file to be truly 'locked', as suggested by Markus.
>
> Also the file is stored on disk somehow, so I thought I may be able to
> directly manipulate the access permissions on a directory / file, I just
> wanted to know if this would work or not. From what I read I understood that
> this was the case, if however SVN silently 'ignores' these types of
> permission that is fair enough, I guess the process runs as a super user,
> which would make sense (most server processes seem to want to have full
> power over their own process, which seems reasonable).
>
> @Daniel
> thanks for the idea of the wrapper scripts
>
> @Markus
> Thanks, I had thought of a custom property already, but I hadn't read
> anything on ' post-commit hook', so I'm off for another look at the manual
> and trawl through google.
>
> Maybe if I can use a post commit hook linked to the files MD5 checksum...
>
> And of course if there any any changes made I will always be able to return
> to the 'correct' version
>
> Thanks again all.
>
> David****
>
> On Mon, Jul 18, 2011 at 8:05 AM, Markus Schaber <m....@3s-software.com>
> wrote:****
>
> Hi, David,
>
> Von: David Myers [mailto:david.myers.24j74@gmail.com]****
>
> > What I require is a method where I can make the file truly 'read only'
> after a certain point.****
>
> My suggestion is a special property you invent yourself (like
> FileFrozenReadonly), and a post-commit hook which prevents commits on
> all files having that property set. You may even combine it with the
> svn:needs-lock property which makes SVN check out the files as
> read-only.
>
>
>
> Best regards
>
> Markus Schaber
>
> ___________________________
> We software Automation.
>
> 3S-Smart Software Solutions GmbH
> Markus Schaber | Developer
> Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 |
> Fax +49-831-54031-50
>
> Email: m.schaber@3s-software.com | Web: http://www.3s-software.com
> CoDeSys internet forum: http://forum.3s-software.com
> Download CoDeSys sample projects:
> http://www.3s-software.com/index.shtml?sample_projects
>
> Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner |
> Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915****
>
>
>
>
> --
> + 33 6 50 14 39 34
>
> email:
> david.myers.24j74@gmail.com
>
> Addres:
> 56 Rue du Coteau du Parc, 91180 Saint Germain les Arpajon.****
>
--
+ 33 6 50 14 39 34
email:
david.myers.24j74@gmail.com
Addres:
56 Rue du Coteau du Parc, 91180 Saint Germain les Arpajon.
AW: Can I prevent a file from being modified?
Posted by Markus Schaber <m....@3s-software.com>.
Hi, David,
Von: David Myers [mailto:david.myers.24j74@gmail.com]
> What I require is a method where I can make the file truly 'read only'
after a certain point.
My suggestion is a special property you invent yourself (like
FileFrozenReadonly), and a post-commit hook which prevents commits on
all files having that property set. You may even combine it with the
svn:needs-lock property which makes SVN check out the files as
read-only.
Best regards
Markus Schaber
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 |
Fax +49-831-54031-50
Email: m.schaber@3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects:
http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner |
Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: Can I prevent a file from being modified?
Posted by Les Mikesell <le...@gmail.com>.
On 7/16/11 3:14 PM, David Myers wrote:
> Dear subversion,
>
> I have recently started a new post and I am in the process of investigating some
> possible new working practices. This particularly relates to document control.
>
> I have read in various places about the 'tagging' system (where by I can use a
> property to effectively 'name' a file) used by subversion and things such as
> svn:needs-lock that forces any user who tries to commit a change to a file to be
> asked to acquire the lock that the file holds.
>
> These almost fit my requirements, but not quite.
>
>
> What I require is a method where I can make the file truly 'read only' after a
> certain point.
> From what I have read in various places I thing I understand that...
> subversion reflects the unix style permissions on it's subdirectories, in the
> subversion directory tree.
> If I want to make a specific location 'read only' I need to do this from a new
> directory, and then files in this directory will acquire the permissions of the
> parent directory.
> subversion doesn't store the file permissions of a file directly it stores it
> within the svn:properties
>
> However if the above statement is correct this may not fill my requirements.
>
> Let me expand on my problem (situation).
>
> A group of users may be working on a file over time. At a certain point they all
> agree that the file is up to its required needs and they formally create a hard
> copy of this file, and store it as a controlled document (signed and counter
> signed blah blah blah).
> The finalised hard copy of the file must be an exact match of the copy stored
> electronically. All the users will be aware that this file shouldn't be change
> on the disk. But life being life when a user opens the file to print it they may
> inadvertently add a space in a paragraph, or an accidental carriage return, or worse
>
> how often have you been working on document1 when you get that phone call to
> ask about a specific part of the controlled document2, so you open the
> document to have a quick read and clarify the situation. Then you get
> distracted by something else and you return and start editing the document2,
> thinking you are editing document1.
> We all know it shouldn't happen but it does occasionally.
>
> What I want to be sure of is that even if this is done by accident there is no
> way that the file on disk in the subversion repository can be inadvertently
> changed. The svn:need-lock property combined with another personal property
> (something along the lines of CtrlDoc:DO_NOT_CHANGE TRUE ), unless there is an
> svn:read-only property that I am yet to come across!
>
> I feel that the combination of these properties and proper use of the Head,
> commit and branch strategies should enable myself and my users to ensure that
> these types of problems don't occur.
>
> Please help me clarify this so as I can propose the use of a subversion to my
> colleagues, and give eloquent and correct answers to any of their queries.
First, subversion provides mechanisms to check for changes against a specified
revision and to retrieve specified revisions into your working copy. Perhaps
you can formalize the way you specify the revision(s) you want to be using or
add checks for changes in files subsequent revisions in your workflow and relax
the requirement to disallow changes. Version control systems are more about
tracking changes than preventing them. If you ask for a specific revision it
will always be the same regardless of changes in subsequent changes. Tags are
sort-of a special case of this where a directory at a certain revision is copied
to a name where you reference it more easily - but you'd get exactly the same
results if you retrieved the source directory of the tag copy and specified the
revision number. Because of the way tags are used, they are normally not
modified after the copy that creates them, either just by convention or by a
pre-commit hook that disallows changes to existing files. If you want to tweak
things at that level, you could modify your pre-commit hook script to prevent
changes to any files you want.
--
Les Mikesell
lesmikesell@gmail.com
Re: Can I prevent a file from being modified?
Posted by Chris Albertson <al...@gmail.com>.
On Sat, Jul 16, 2011 at 1:14 PM, David Myers
<da...@gmail.com> wrote:
> Dear subversion,
>
> I have recently started a new post and I am in the process of investigating
> some possible new working practices. This particularly relates to document
> control.
No matter how good or what features you have in SVN or some other
system like it, there is the chance that after the document is checked
out it is modified. I think you need to have workflow and practices
to prevent and detect a change that might happen outside of svn. A
couple things I can think of are (1) COmpute the MD5 checksum and
store that as a seporate text file. If ever you find the MD5 and the
document no longer match you know one of them is changed. (2) many
document file formats and be set to disallow edits. PDF can bet set
this way.
WithSVN I think all you need is a way to DETECT changes because you
can always back them out if you know the change was made. An MD5
checksum is a good way to detect changes
--
Chris Albertson
Redondo Beach, California
Re: Can I prevent a file from being modified?
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag David Myers,
am Samstag, 16. Juli 2011 um 22:14 schrieben Sie:
> Please help me clarify this so as I can propose the use of a subversion
> to my colleagues, and give eloquent and correct answers to any of their
> queries.
First of all, nothing is committed automatically by default and
therefore can not be committed by accident. Even in your described
scenario of accidently changing a file which shouldn't have changed,
it doesn't get committed automatically. One has to commit the file as
a separate process. It may be possible that the changed file gets
committed by accident with other changes which should get committed,
but this depends on your repository layout and therefore can be
prevented by proper layout. So, do you really need the administrative
overhead of making the file read only?
If you really want it read only, I would just use path based
authorization with a group which consists of all users which normally
modify the files in question, therefore have granted write permissions
and after they agree that nor further modification is needed, change
write to read permissions.
http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig.pathbasedauthz
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
Telefon: Potsdam: 0331-743881-0
E-Mail: tschoening@am-soft.de
Web: http://www.am-soft.de
AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
Re: Can I prevent a file from being modified?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Ryan Schmidt wrote on Sun, Jul 17, 2011 at 15:35:20 -0500:
>
> On Jul 16, 2011, at 15:14, David Myers wrote:
>
> > From what I have read in various places I thing I understand that...
> > subversion reflects the unix style permissions on it's subdirectories, in the subversion directory tree.
> > If I want to make a specific location 'read only' I need to do this from a new directory, and then files in this directory will acquire the permissions of the parent directory.
> > subversion doesn't store the file permissions of a file directly it stores it within the svn:properties
>
> Where did you read this? I don't think any of that is true. Subversion
> does not store permissions. There is no such thing as
> "svn:properties". The only permission Subversion can store is a file's
> execute bit; set the "svn:executable" property to an asterisk ("*") to
(any value will do; "*" is fine as long as one remembers to shell-quote it)
> indicate the file should have the execute bit, or delete that property
> to indicate it should not.
>
Also, svn:needs-lock files will be checked out as read-only until
they're "svn lock"ed. But we don't store permissions beyond that.
(There are wrapper scripts that do so, but Subversion itself doesn't.)
>
Re: Can I prevent a file from being modified?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Jul 16, 2011, at 15:14, David Myers wrote:
> From what I have read in various places I thing I understand that...
> subversion reflects the unix style permissions on it's subdirectories, in the subversion directory tree.
> If I want to make a specific location 'read only' I need to do this from a new directory, and then files in this directory will acquire the permissions of the parent directory.
> subversion doesn't store the file permissions of a file directly it stores it within the svn:properties
Where did you read this? I don't think any of that is true. Subversion does not store permissions. There is no such thing as "svn:properties". The only permission Subversion can store is a file's execute bit; set the "svn:executable" property to an asterisk ("*") to indicate the file should have the execute bit, or delete that property to indicate it should not.