You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Grant <em...@gmail.com> on 2011/09/29 04:41:34 UTC
File access control
I see that subversion supports path-based authorization:
http://svnbook.red-bean.com/en/1.5/svn.serverconfig.pathbasedauthz.html
Is there a way to do file-based authorization? Or maybe some sort of
trickery to mimic file-based authorization? If not, can anyone think
of a way to allow read/write access to only certain files in a working
system? I could use chmod/chown but the files to which access is
allowed will be changing pretty frequently so it would be nice to have
accessible files defined in a list as part of the version control
system, file transport mechanism, or anything else.
- Grant
Re: File access control
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Grant,
am Donnerstag, 29. September 2011 um 04:41 schrieben Sie:
> Is there a way to do file-based authorization?
Not that I read of.
> Or maybe some sort of
> trickery to mimic file-based authorization?
You can always create folders, depending on what exactly you have to
protect against whom.
> If not, can anyone think
> of a way to allow read/write access to only certain files in a working
> system?
Do you mean a working copy? If so, this is no option at all because
the working copy is controlled by the person you want to protect your
files against.
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: File access control
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Sep 29, 2011, at 10:02, Thorsten Schöning wrote:
> I didn't try, but if it works it would be nice to get that mentioned
> in the book. I always thought directories are all which is possible.
You should submit that feedback to the people who write the book. They have a separate mailing list.
Re: File access control
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Mark Phippard,
am Donnerstag, 29. September 2011 um 14:37 schrieben Sie:
> Files are paths too. The path-based authz applies to any path (folder
> or file). For example:
> [repos:/trunk/readme.txt]
> @releng = rw
> * = r
> A rule like that works fine.
I didn't try, but if it works it would be nice to get that mentioned
in the book. I always thought directories are all which is possible.
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: File access control
Posted by Chris Albertson <al...@gmail.com>.
On Fri, Sep 30, 2011 at 7:16 PM, Grant <em...@gmail.com> wrote:
> Is it risky because I would be using rsync instead of svn update, or
> is it risky because I wouldn't be using a test/staging machine? Why
> can't testing be done on the dev machine?
risky because you can't 100% prove what you got is exactly what is in
SVN. If you check the code out and then rsync it you might
accidentally make a change between checkout and rsync. But if you
do the checkout direct to the end-user machine you know what you got
can straight out of svn.
That said most people don't do that. Part of what you ask your dev
to do is create an "install bundle" on most UNIX-likemacnines this is
a .tar file. in Windows it's an installer. on Mac it's a disk image
.dmg file Then you move those to the end user
--
Chris Albertson
Redondo Beach, California
Re: File access control
Posted by Les Mikesell <le...@gmail.com>.
On Sat, Oct 1, 2011 at 6:15 PM, Grant <em...@gmail.com> wrote:
>
> Would I need to install subversion on the production machine, or would
> the subversion server running on the dev machine just treat the
> production machine as a target destination and use SSH to transfer the
> files?
How you move things around isn't as important as knowing what you are
moving. And it doesn't really matter where the working copies are or
how many you have.
> So I'll be OK if I commit changes to the dev repository and then
> update from dev to production instead of using rsync.
Yes, that would assure that you can update to a known rev or tag. But
so would any other working copy and using rsync from there. If it is
convenient to use svn as a transport, go ahead but it isn't necessary.
> I'm trying to get the dev/staging/production thing clear in my mind.
> The way I imagine this working is I install a copy of my production
> machine onto a dev machine and a developer works on some of the code
> on that dev machine and is able to test his changes on that machine as
> he goes. Once everything is done and verified, his changes are
> exported to the production machine. Where does the staging machine
> come in? Why is it needed in addition to the dev machine?
You don't necessarily need another machine for staging, just a
separate working copy. You may want dev work to continue on a
different schedule than your testing and releases.
> I can see how multiple developers would really complicate things. Now
> that I think about it, wouldn't development on the dev machine be
> impossible if two developers are working on separate things that
> happen to interact with each other? They wouldn't be able to test
> their changes properly as they're coding. How is that handled? A
> separate dev machine for each developer?
In a larger scenario, each developer would have his own working copy
and likely a test environment (perhaps but not necessarily on separate
machines). If their changes aren't likely to conflict, they can
simply commit/update to pick up each others' work. If the changes
may conflict or some of the work won't be released until later you
would use branches to isolate it. And at some point the separate
test/staging becomes more important as you need to integrate and test
changes that were developed separately.
--
Les Mikesell
lesmikesell@gmail.com
Re: File access control
Posted by Andreas Krey <a....@gmx.de>.
On Sat, 01 Oct 2011 18:07:29 +0000, Grant wrote:
...
> Ouch. If testing is done on the developer's local machine, he will
> need a full working copy and it will be impossible to restrict read
> access to one or a few files as I had planned to do with path-based
> authz. Instead, could I check out a working copy of the repository to
> a staging machine of mine and allow the developer to check out only
> one or a few files as defined via path-based authz, thereby requiring
> him to commit his changes and update the staging machine's working
> copy in order to test his changes and debug?
First of all, either he would need permission to do the 'svn up' on
the staging machine, which, unless you do some sudo magic, would give
him access to all the code, or you need to set things up so the
staging area do update itself automatically on every commit made.
Both is possible.
But: In essence this setup means that I, the developer, have to commit
every time I want to test something. Sometimes, that would mean three
times a minute. This is a major nuisance for the devs, and it also
means that the history accumulated is pretty much worthless, both
because nobody will do meaningful commit messages and because there
are no meaningful commits.
> I suppose each developer
> would require a separate staging machine to work this way.
In addition it means that you *need* a branch for every dev's work,
because otherwise you are basically back to 'everyone edits the master
copy', and that you are the only one who can do merges anyway.
> I'm really getting the square peg round hole feeling. The workflow
> you describe is elegant and very enticing but it gives all of my code
> away. The prevailing attitude seems to be that developers should be
> trusted,
If you don't trust me not to run away with the code, why should
I trust you to pay me at the end of the month/contract?
> but this goes against everything I've learned about system
> administration where security is taken seriously and trust doesn't cut
Well, if I was serious about getting at your code I would try to
hack your production web server, or to get into an admin position
at your company. Or cleaning personnel. :-)
If you don't actually not want devs to *see* other code then you
should instead aim on physical security. No external drives on the
machines, no internet or something SElinuxy to prevent copies out
of the secured part into the mailer or such.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: File access control
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Grant,
am Sonntag, 2. Oktober 2011 um 03:07 schrieben Sie:
> All of the big enterprise websites allow each of their developers to
> check out a full working copy of the company code with only an NDA/NCC
> to protect them?
Mostly, yes and why do you think this is not enough?
> It would be so easy for any of them to use, sell, or
> give the code away, or even to accidentally allow an unauthorized
> person access to it.
No hard feelings, but your thread doesn't read that whatever you try
to protect is interesting enough for anyone out there to justify the
time you spent on thinking about how to protect your code against god
and the world. You speak of hiring a developer, if it's not the son
of a friend who worked with computers in school, but a professional,
he will act like a professional if he wants to get paid without
problems.
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: File access control
Posted by David Chapman <dc...@acm.org>.
On 10/1/2011 8:26 PM, Grant wrote:
>>> Ouch. If testing is done on the developer's local machine, he will need a
>>> full working copy and it will be impossible to restrict read access to one
>>> or a few files as I had planned to do with path-based authz. Instead, could
>>> I check out a working copy of the repository to a staging machine of mine
>>> and allow the developer to check out only one or a few files as defined via
>>> path-based authz, thereby requiring him to commit his changes and update the
>>> staging machine's working copy in order to test his changes and debug? I
>>> suppose each developer would require a separate staging machine to work this
>>> way.
>> If a developer has access to only part of the Web site, he/she will be able
>> to test only part of the Web site. That is not scalable in the long run.
>> As soon as one part of the Web site relies on another for functioning, your
>> development methodology will break.
> Your post has given me a lot to think about, but I don't agree that
> one part of the website relying on another part means the development
> methodology will break. Whenever something needs to be worked on, I
> would give the developer access to all necessary files. If it turns
> out I didn't grant access to enough files, I can always add one or
> more files to the accessible list. Can you give me an example of a
> situation that would break my proposed development methodology?
>
Easy: you go out to lunch right before your developer finds he/she
needs a file. Now you're paying for someone to sit and wait for you to
come back from lunch. Any time you are not immediately available to
change the permissions, you are losing money.
"Not scalable" means that the management burden will grow tremendously
as the amount of code in your Web site grows. You may be willing to
adjust the permissions list regularly if there are only 100 files, but
what if there are 1,000? Or 10,000? What if there are 20 developers?
Or 50? What if some of them are in Europe, or India? For every
project, for every developer, you are going to have to build a list of
files to access, and that list is likely to need tuning as the project
proceeds.
Limits on source code access are very common; for example, a developer
working on analysis software doesn't need to see the internals of the
GUI (and vice versa). Usually the source code for different products is
in different directories, making access control manageable. It requires
some work to partition code, but the way of thinking it induces is good
for Software Engineering (as opposed to hacking something together).
I'm not a commercial Web site developer, but I would expect that any
feature which involves a fair amount of computation is going to require
quite a bit of code. You're going to want to isolate that code (with
APIs etc.) for testability anyway; why not move it into a separate
directory?
Look back at the statement you made above: you are willing to make
testing more difficult in order to protect your source code. If testing
is harder, less will be done - it's human nature. That could easily
degrade the quality of the product to be delivered. Most companies
accept the theft risk (using the legal system as a hammer) in order to
get a higher quality product. That's why you're finding so little
support for your methodology in the tools.
--
David Chapman dcchapman@acm.org
Chapman Consulting -- San Jose, CA
Re: File access control
Posted by Grant <em...@gmail.com>.
>> Ouch. If testing is done on the developer's local machine, he will need a
>> full working copy and it will be impossible to restrict read access to one
>> or a few files as I had planned to do with path-based authz. Instead, could
>> I check out a working copy of the repository to a staging machine of mine
>> and allow the developer to check out only one or a few files as defined via
>> path-based authz, thereby requiring him to commit his changes and update the
>> staging machine's working copy in order to test his changes and debug? I
>> suppose each developer would require a separate staging machine to work this
>> way.
>
> If a developer has access to only part of the Web site, he/she will be able
> to test only part of the Web site. That is not scalable in the long run.
> As soon as one part of the Web site relies on another for functioning, your
> development methodology will break.
Your post has given me a lot to think about, but I don't agree that
one part of the website relying on another part means the development
methodology will break. Whenever something needs to be worked on, I
would give the developer access to all necessary files. If it turns
out I didn't grant access to enough files, I can always add one or
more files to the accessible list. Can you give me an example of a
situation that would break my proposed development methodology?
- Grant
>> I'm really getting the square peg round hole feeling. The workflow
>> you describe is elegant and very enticing but it gives all of my code
>> away. The prevailing attitude seems to be that developers should be
>> trusted, but this goes against everything I've learned about system
>> administration where security is taken seriously and trust doesn't cut
>> it. I could go the NDA/NCC route but that seems only slightly more
>> secure than trust to me.
>
> "Gives all my code away" is really an exaggeration; as soon as you have
> employees (contract or otherwise), there will be more than one person who
> knows the code. It is said that the most valuable assets of Silicon Valley
> corporations go home at night - i.e. it is the employees and their knowledge
> who are valuable, and not the source code.
>
> I personally know of one major corporation with a 15 million line code base
> "and no one person understands all of it" (quoted from an employee). The
> developers in that group can see all of the source code if they need to, but
> it is their collective knowledge that keeps the program valuable and not the
> source code itself. The company has NDAs and other legal agreements with
> its employees and contractors, and all of them know they will be sued if
> they walk away with that source code. And that is all the company can do.
>
> The walled-off approach can only work if the pieces are truly independent,
> and that requires significant design effort up front. If your files are all
> in one directory, you're just asking for a security leak (by your
> definition) - one mistaken permission setting, and that secret is out.
> Directory-level permissions are much easier to manage because there is only
> one permission setting to track. Security is simpler when there are fewer
> points of attack; a file-level system is going to be wide open.
>
>
>> All of the big enterprise websites allow each of their developers to
>> check out a full working copy of the company code with only an NDA/NCC
>> to protect them? It would be so easy for any of them to use, sell, or
>> give the code away, or even to accidentally allow an unauthorized
>> person access to it.
>>
>>
>
> I can't speak for Web sites, but in the rest of the software world,
> developers can see all of the source code for the product they are working
> on. Otherwise they can't debug it; the first time a crash occurs in some
> other code, the developer is dead in the water until the error can be handed
> over to a responsible party. Basically, if it is in the same executable,
> the developer needs to see the source code.
>
> It's tempting to protect your interests by blocking all access except for a
> very small window, but the productivity cost is generally judged to be too
> high.
>
> --
> David Chapman dcchapman@acm.org
> Chapman Consulting -- San Jose, CA
Re: File access control
Posted by David Chapman <dc...@acm.org>.
On 10/1/2011 6:07 PM, Grant wrote:
> Ouch. If testing is done on the developer's local machine, he will
> need a full working copy and it will be impossible to restrict read
> access to one or a few files as I had planned to do with path-based
> authz. Instead, could I check out a working copy of the repository to
> a staging machine of mine and allow the developer to check out only
> one or a few files as defined via path-based authz, thereby requiring
> him to commit his changes and update the staging machine's working
> copy in order to test his changes and debug? I suppose each developer
> would require a separate staging machine to work this way.
If a developer has access to only part of the Web site, he/she will be
able to test only part of the Web site. That is not scalable in the
long run. As soon as one part of the Web site relies on another for
functioning, your development methodology will break.
> I'm really getting the square peg round hole feeling. The workflow
> you describe is elegant and very enticing but it gives all of my code
> away. The prevailing attitude seems to be that developers should be
> trusted, but this goes against everything I've learned about system
> administration where security is taken seriously and trust doesn't cut
> it. I could go the NDA/NCC route but that seems only slightly more
> secure than trust to me.
"Gives all my code away" is really an exaggeration; as soon as you have
employees (contract or otherwise), there will be more than one person
who knows the code. It is said that the most valuable assets of Silicon
Valley corporations go home at night - i.e. it is the employees and
their knowledge who are valuable, and not the source code.
I personally know of one major corporation with a 15 million line code
base "and no one person understands all of it" (quoted from an
employee). The developers in that group can see all of the source code
if they need to, but it is their collective knowledge that keeps the
program valuable and not the source code itself. The company has NDAs
and other legal agreements with its employees and contractors, and all
of them know they will be sued if they walk away with that source code.
And that is all the company can do.
The walled-off approach can only work if the pieces are truly
independent, and that requires significant design effort up front. If
your files are all in one directory, you're just asking for a security
leak (by your definition) - one mistaken permission setting, and that
secret is out. Directory-level permissions are much easier to manage
because there is only one permission setting to track. Security is
simpler when there are fewer points of attack; a file-level system is
going to be wide open.
> All of the big enterprise websites allow each of their developers to
> check out a full working copy of the company code with only an NDA/NCC
> to protect them? It would be so easy for any of them to use, sell, or
> give the code away, or even to accidentally allow an unauthorized
> person access to it.
>
>
I can't speak for Web sites, but in the rest of the software world,
developers can see all of the source code for the product they are
working on. Otherwise they can't debug it; the first time a crash
occurs in some other code, the developer is dead in the water until the
error can be handed over to a responsible party. Basically, if it is in
the same executable, the developer needs to see the source code.
It's tempting to protect your interests by blocking all access except
for a very small window, but the productivity cost is generally judged
to be too high.
--
David Chapman dcchapman@acm.org
Chapman Consulting -- San Jose, CA
Re: File access control
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Oct 1, 2011, at 20:07, Grant wrote:
>> There is a repository -- a database -- that holds your code. The current version and all past versions, including, if you like, branches. This could be on any server you like -- the production server, the development server, a completely separate server -- doesn't really matter. That server will run some kind of Subversion server software -- svnserve perhaps, or Apache 2 with mod_dav_svn.
>>
>> Anyone who works on the code will check out a working copy from the repository onto their work machine. They will modify the code, then they will test the changes on their local work machine (which in your case means they will be running a web server and whatever else necessary to run the web site on their work machine). Once satisfied the changes are correct, they'll commit the changes back to the repository, with a message describing what they did.
>
> Ouch. If testing is done on the developer's local machine, he will
> need a full working copy and it will be impossible to restrict read
> access to one or a few files as I had planned to do with path-based
> authz. Instead, could I check out a working copy of the repository to
> a staging machine of mine and allow the developer to check out only
> one or a few files as defined via path-based authz, thereby requiring
> him to commit his changes and update the staging machine's working
> copy in order to test his changes and debug? I suppose each developer
> would require a separate staging machine to work this way.
>
> I'm really getting the square peg round hole feeling. The workflow
> you describe is elegant and very enticing but it gives all of my code
> away. The prevailing attitude seems to be that developers should be
> trusted, but this goes against everything I've learned about system
> administration where security is taken seriously and trust doesn't cut
> it. I could go the NDA/NCC route but that seems only slightly more
> secure than trust to me.
>
> All of the big enterprise websites allow each of their developers to
> check out a full working copy of the company code with only an NDA/NCC
> to protect them? It would be so easy for any of them to use, sell, or
> give the code away, or even to accidentally allow an unauthorized
> person access to it.
You're right, your restriction of not wanting to give the developer access to all the files needed to make the web site function does complicate matters. It's a situation I didn't have to deal with in the web development shop where I worked. We didn't use authz; everyone had access to everything.
Usually, you want to test your work before you commit it. But in your case you might adopt a different policy, of allowing people to commit work, in order to then test it on a central development server. The development server could have a full working copy of the site, and could be configured with a post-commit hook to automatically update itself after every commit:
http://subversion.apache.org/faq.html#website-auto-update
Nobody would have permission to modify that working copy in any way; only the server itself would have the ability to update it, by running "svn update". This ensures it's a pristine copy of what's in the repository.
You could grant your untrusted developers access to relevant parts of the repository using authz, which they would check out to their local machines, modify, commit, and then access your dev server's central URL to see if their changes worked. If not, they'd make another change and commit, until things worked.
Instead of having this developer modify the trunk, you might give them access to a special branch of the code. This way their changes are isolated from your trusted developers, or even from other untrusted developers. Somebody trusted then takes on the task of merging their work into the trunk when it's done.
In this scenario, you might indeed set up a separate virtual host (separate instance of the app, separate dev server working copy) for each such branch. No need for there to be separate servers though.
Re: File access control
Posted by Grant <em...@gmail.com>.
> Again I strongly encourage you to spend time reading the book. The first several chapters should solidify for you how people work with Subversion. There's no sense in us explaining it all here on the list when writers have already spent years refining the words in the book. But I'll try to summarize a few things briefly anyway:
Thank you Ryan. Your description is very much illuminating.
> There is a repository -- a database -- that holds your code. The current version and all past versions, including, if you like, branches. This could be on any server you like -- the production server, the development server, a completely separate server -- doesn't really matter. That server will run some kind of Subversion server software -- svnserve perhaps, or Apache 2 with mod_dav_svn.
>
> Anyone who works on the code will check out a working copy from the repository onto their work machine. They will modify the code, then they will test the changes on their local work machine (which in your case means they will be running a web server and whatever else necessary to run the web site on their work machine). Once satisfied the changes are correct, they'll commit the changes back to the repository, with a message describing what they did.
Ouch. If testing is done on the developer's local machine, he will
need a full working copy and it will be impossible to restrict read
access to one or a few files as I had planned to do with path-based
authz. Instead, could I check out a working copy of the repository to
a staging machine of mine and allow the developer to check out only
one or a few files as defined via path-based authz, thereby requiring
him to commit his changes and update the staging machine's working
copy in order to test his changes and debug? I suppose each developer
would require a separate staging machine to work this way.
I'm really getting the square peg round hole feeling. The workflow
you describe is elegant and very enticing but it gives all of my code
away. The prevailing attitude seems to be that developers should be
trusted, but this goes against everything I've learned about system
administration where security is taken seriously and trust doesn't cut
it. I could go the NDA/NCC route but that seems only slightly more
secure than trust to me.
All of the big enterprise websites allow each of their developers to
check out a full working copy of the company code with only an NDA/NCC
to protect them? It would be so easy for any of them to use, sell, or
give the code away, or even to accidentally allow an unauthorized
person access to it.
- Grant
> At any time you can choose to pull a version of the files from the repository and put them on a staging web server for testing, or on a production web server. How you do so is up to you. Generally you would "tag" your code before you put it anywhere, so that you give that state of the code a meaningful name that can be referred to later as needed.
>
> If any of the above sounds unfamiliar then you really need to spend more time with the book.
>
> The book doesn't specifically address developing web sites with Subversion, but it's not too difficult. If the web servers can reach the repository server, you can go to the web server and check out or update a working copy from the repository server directly. If not, you can use any other computer to get a working copy from the repository, and scp or ftp or rsync that to the web server. Or you could automate deployment using tools like SVN::Notify::Mirror, which watches your repository for the creation of tags following a certain naming convention (that you define) and deploys those versions. (I recommend this approach.)
Re: File access control
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Oct 1, 2011, at 18:15, Grant wrote:
> Would I need to install subversion on the production machine, or would
> the subversion server running on the dev machine just treat the
> production machine as a target destination and use SSH to transfer the
> files?
> So I'll be OK if I commit changes to the dev repository and then
> update from dev to production instead of using rsync.
>
> I'm trying to get the dev/staging/production thing clear in my mind.
> The way I imagine this working is I install a copy of my production
> machine onto a dev machine and a developer works on some of the code
> on that dev machine and is able to test his changes on that machine as
> he goes. Once everything is done and verified, his changes are
> exported to the production machine. Where does the staging machine
> come in? Why is it needed in addition to the dev machine?
>
> I can see how multiple developers would really complicate things. Now
> that I think about it, wouldn't development on the dev machine be
> impossible if two developers are working on separate things that
> happen to interact with each other? They wouldn't be able to test
> their changes properly as they're coding. How is that handled? A
> separate dev machine for each developer?
>
> I think I'm missing something here. Could someone straighten me out?
Again I strongly encourage you to spend time reading the book. The first several chapters should solidify for you how people work with Subversion. There's no sense in us explaining it all here on the list when writers have already spent years refining the words in the book. But I'll try to summarize a few things briefly anyway:
There is a repository -- a database -- that holds your code. The current version and all past versions, including, if you like, branches. This could be on any server you like -- the production server, the development server, a completely separate server -- doesn't really matter. That server will run some kind of Subversion server software -- svnserve perhaps, or Apache 2 with mod_dav_svn.
Anyone who works on the code will check out a working copy from the repository onto their work machine. They will modify the code, then they will test the changes on their local work machine (which in your case means they will be running a web server and whatever else necessary to run the web site on their work machine). Once satisfied the changes are correct, they'll commit the changes back to the repository, with a message describing what they did.
At any time you can choose to pull a version of the files from the repository and put them on a staging web server for testing, or on a production web server. How you do so is up to you. Generally you would "tag" your code before you put it anywhere, so that you give that state of the code a meaningful name that can be referred to later as needed.
If any of the above sounds unfamiliar then you really need to spend more time with the book.
The book doesn't specifically address developing web sites with Subversion, but it's not too difficult. If the web servers can reach the repository server, you can go to the web server and check out or update a working copy from the repository server directly. If not, you can use any other computer to get a working copy from the repository, and scp or ftp or rsync that to the web server. Or you could automate deployment using tools like SVN::Notify::Mirror, which watches your repository for the creation of tags following a certain naming convention (that you define) and deploys those versions. (I recommend this approach.)
Re: File access control
Posted by Grant <em...@gmail.com>.
>> After committing changes to the repository on the dev machine, could I
>> use svn update instead of rsync to bring the production machine's
>> files in sync with those on the dev machine?
>
> Yes, and even better if you have an intermediate staging/testing
> space, but that may be overkill for some situations.
Would I need to install subversion on the production machine, or would
the subversion server running on the dev machine just treat the
production machine as a target destination and use SSH to transfer the
files?
>>> on that are possible, but you really don't want to set up a path that
>>> has a way to get something into production that wasn't committed as a
>>> known revision or tag. Rsyncing from a test/staging copy to
>>> production is probably ok - going straight from the development
>>> workspace where changes are being made would be more risky.
>>
>> Is it risky because I would be using rsync instead of svn update, or
>> is it risky because I wouldn't be using a test/staging machine? Why
>> can't testing be done on the dev machine?
>
> One of the things you get from version control is the ability to roll
> back to any version that was ever committed. If you move things
> directly from the development workspace to production, you have the
> opportunity to copy something in that has not been committed to the
> repository. Now, if you make additional changes, and the next
> version has a problem, you won't be able to roll back or even see the
> differences from the now overwritten version that worked previously.
> You could use other procedures to make sure that the version that is
> put in production exactly matches a committed revision, but the easy
> way is to use a workflow where the only way to move files is to commit
> from the place where the changes are made, and update in a different
> workspace. Also if you ever have more than one developer doing
> changes at the same time, you may want that separate testing workspace
> where you make sure that all the parts still work together.
So I'll be OK if I commit changes to the dev repository and then
update from dev to production instead of using rsync.
I'm trying to get the dev/staging/production thing clear in my mind.
The way I imagine this working is I install a copy of my production
machine onto a dev machine and a developer works on some of the code
on that dev machine and is able to test his changes on that machine as
he goes. Once everything is done and verified, his changes are
exported to the production machine. Where does the staging machine
come in? Why is it needed in addition to the dev machine?
I can see how multiple developers would really complicate things. Now
that I think about it, wouldn't development on the dev machine be
impossible if two developers are working on separate things that
happen to interact with each other? They wouldn't be able to test
their changes properly as they're coding. How is that handled? A
separate dev machine for each developer?
I think I'm missing something here. Could someone straighten me out?
- Grant
Re: File access control
Posted by Les Mikesell <le...@gmail.com>.
On Fri, Sep 30, 2011 at 9:16 PM, Grant <em...@gmail.com> wrote:
>> Normally you would do that with a subversion client, creating
>> different workspaces for development, testing, and production with
>> commit/update operations to move data instead of rsync. Variations
>
> After committing changes to the repository on the dev machine, could I
> use svn update instead of rsync to bring the production machine's
> files in sync with those on the dev machine?
Yes, and even better if you have an intermediate staging/testing
space, but that may be overkill for some situations.
>> on that are possible, but you really don't want to set up a path that
>> has a way to get something into production that wasn't committed as a
>> known revision or tag. Rsyncing from a test/staging copy to
>> production is probably ok - going straight from the development
>> workspace where changes are being made would be more risky.
>
> Is it risky because I would be using rsync instead of svn update, or
> is it risky because I wouldn't be using a test/staging machine? Why
> can't testing be done on the dev machine?
One of the things you get from version control is the ability to roll
back to any version that was ever committed. If you move things
directly from the development workspace to production, you have the
opportunity to copy something in that has not been committed to the
repository. Now, if you make additional changes, and the next
version has a problem, you won't be able to roll back or even see the
differences from the now overwritten version that worked previously.
You could use other procedures to make sure that the version that is
put in production exactly matches a committed revision, but the easy
way is to use a workflow where the only way to move files is to commit
from the place where the changes are made, and update in a different
workspace. Also if you ever have more than one developer doing
changes at the same time, you may want that separate testing workspace
where you make sure that all the parts still work together.
--
Les Mikesell
lesmikesell@gmail.com
Re: File access control
Posted by Grant <em...@gmail.com>.
>> My workflow above only describes a single repository on the dev
>> machine, the production machine wouldn't have a repository. rsync
>> would synchronize the source files, not the repository.
>>
>
> Normally you would do that with a subversion client, creating
> different workspaces for development, testing, and production with
> commit/update operations to move data instead of rsync. Variations
After committing changes to the repository on the dev machine, could I
use svn update instead of rsync to bring the production machine's
files in sync with those on the dev machine?
> on that are possible, but you really don't want to set up a path that
> has a way to get something into production that wasn't committed as a
> known revision or tag. Rsyncing from a test/staging copy to
> production is probably ok - going straight from the development
> workspace where changes are being made would be more risky.
Is it risky because I would be using rsync instead of svn update, or
is it risky because I wouldn't be using a test/staging machine? Why
can't testing be done on the dev machine?
- Grant
Re: File access control
Posted by Les Mikesell <le...@gmail.com>.
On Fri, Sep 30, 2011 at 8:46 PM, Grant <em...@gmail.com> wrote:
>
> My workflow above only describes a single repository on the dev
> machine, the production machine wouldn't have a repository. rsync
> would synchronize the source files, not the repository.
>
Normally you would do that with a subversion client, creating
different workspaces for development, testing, and production with
commit/update operations to move data instead of rsync. Variations
on that are possible, but you really don't want to set up a path that
has a way to get something into production that wasn't committed as a
known revision or tag. Rsyncing from a test/staging copy to
production is probably ok - going straight from the development
workspace where changes are being made would be more risky.
--
Les Mikesell
lesmikesell@gmail.com
Re: File access control
Posted by Grant <em...@gmail.com>.
>> Right now I'm trying to decide whether or not I should use subversion.
>> Hopefully there is a less time-consuming method for making that
>> determination.
>>
>> My goals are to implement a good development framework and to define a
>> (changing) list of files which are the only files a developer is
>> allowed to either read or write. If I can do that with subversion and
>> path-based authorization, I'd like to get an idea of the workflow
>> involved. Here is a modified version of my proposed workflow.
>> Hopefully it is more intelligent than my last attempt:
>>
>> 1. I install a subversion server on my dev machine.
>> 2. I decide which file or files I want my dev to work on and give him
>> read/write access to only those files (and neither read nor write
>> access to any other files) via path-based authorization on the
>> subversion server.
>> 3. The dev uses a subversion client over an encrypted connection to
>> edit the permissible files. He can test his changes via http on the
>> dev machine.
>> 4. Once he is done, I test his changes via http on the dev machine and
>> use svn log to look at the specific changes he made.
>> 5. I use rsync to copy the changes made to the dev machine's files to
>> the production machine.
>> 6. Steps 2-5 are repeated.
>>
>> Is this any better?
>
> No, forget the part about copying/duplicating the subversion
> respository. If you are going to use subversion at all, you should
> have one authoritative copy of the repository/server. You can make
> the developer work on a branch within the repository and you can
> either switch the server to a checked out copy of the branch or you
> can merge the approved changes back to the trunk. But any way you
> approach it, if you don't want a single repository holding all work,
> you probably don't want to use subversion.
My workflow above only describes a single repository on the dev
machine, the production machine wouldn't have a repository. rsync
would synchronize the source files, not the repository.
- Grant
Re: File access control
Posted by Les Mikesell <le...@gmail.com>.
On Fri, Sep 30, 2011 at 8:16 PM, Grant <em...@gmail.com> wrote:
>
> Right now I'm trying to decide whether or not I should use subversion.
> Hopefully there is a less time-consuming method for making that
> determination.
>
> My goals are to implement a good development framework and to define a
> (changing) list of files which are the only files a developer is
> allowed to either read or write. If I can do that with subversion and
> path-based authorization, I'd like to get an idea of the workflow
> involved. Here is a modified version of my proposed workflow.
> Hopefully it is more intelligent than my last attempt:
>
> 1. I install a subversion server on my dev machine.
> 2. I decide which file or files I want my dev to work on and give him
> read/write access to only those files (and neither read nor write
> access to any other files) via path-based authorization on the
> subversion server.
> 3. The dev uses a subversion client over an encrypted connection to
> edit the permissible files. He can test his changes via http on the
> dev machine.
> 4. Once he is done, I test his changes via http on the dev machine and
> use svn log to look at the specific changes he made.
> 5. I use rsync to copy the changes made to the dev machine's files to
> the production machine.
> 6. Steps 2-5 are repeated.
>
> Is this any better?
No, forget the part about copying/duplicating the subversion
respository. If you are going to use subversion at all, you should
have one authoritative copy of the repository/server. You can make
the developer work on a branch within the repository and you can
either switch the server to a checked out copy of the branch or you
can merge the approved changes back to the trunk. But any way you
approach it, if you don't want a single repository holding all work,
you probably don't want to use subversion.
--
Les Mikesell
lesmikesell@gmail.com
Re: File access control
Posted by Grant <em...@gmail.com>.
>> That's great news. I've never used a version control system or any
>> sort of developer framework. Would something like this work?
>
> I'm sorry but it really does sound like you have no idea how Subversion works. Please spend several days reading the book front to back:
>
> http://svnbook.org/
Right now I'm trying to decide whether or not I should use subversion.
Hopefully there is a less time-consuming method for making that
determination.
My goals are to implement a good development framework and to define a
(changing) list of files which are the only files a developer is
allowed to either read or write. If I can do that with subversion and
path-based authorization, I'd like to get an idea of the workflow
involved. Here is a modified version of my proposed workflow.
Hopefully it is more intelligent than my last attempt:
1. I install a subversion server on my dev machine.
2. I decide which file or files I want my dev to work on and give him
read/write access to only those files (and neither read nor write
access to any other files) via path-based authorization on the
subversion server.
3. The dev uses a subversion client over an encrypted connection to
edit the permissible files. He can test his changes via http on the
dev machine.
4. Once he is done, I test his changes via http on the dev machine and
use svn log to look at the specific changes he made.
5. I use rsync to copy the changes made to the dev machine's files to
the production machine.
6. Steps 2-5 are repeated.
Is this any better?
- Grant
Re: File access control
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Sep 30, 2011, at 18:37, Grant wrote:
> That's great news. I've never used a version control system or any
> sort of developer framework. Would something like this work?
I'm sorry but it really does sound like you have no idea how Subversion works. Please spend several days reading the book front to back:
http://svnbook.org/
That should give you a better idea.
As for using Subversion to develop a web site, that can be done. But it's probably only confusing to you if we try to explain these additional details when you don't know the basics yet.
Re: File access control
Posted by Grant <em...@gmail.com>.
>> I see that subversion supports path-based authorization:
>>
>> http://svnbook.red-bean.com/en/1.5/svn.serverconfig.pathbasedauthz.html
>>
>> Is there a way to do file-based authorization? Or maybe some sort of
>> trickery to mimic file-based authorization? If not, can anyone think
>> of a way to allow read/write access to only certain files in a working
>> system? I could use chmod/chown but the files to which access is
>> allowed will be changing pretty frequently so it would be nice to have
>> accessible files defined in a list as part of the version control
>> system, file transport mechanism, or anything else.
>
> Files are paths too. The path-based authz applies to any path (folder
> or file). For example:
>
> [repos:/trunk/readme.txt]
> @releng = rw
> * = r
>
> A rule like that works fine.
That's great news. I've never used a version control system or any
sort of developer framework. Would something like this work?
I set up a dev machine, install subversion, and copy all necessary
files from my production machine to the dev machine. I decide which
file or files I want my dev to work on and give him read/write access
to only those files (and neither read nor write access to any other
files) via path-based authz on the dev machine. He uses subversion to
edit the permissible files and test his changes on the dev machine.
Once he is done, I test the dev machine to verify everything is
working after his changes, take a look at the specific code changes he
made, and then import the changes to the production machine. Then I
change the files he has access to via path-based authz and repeat the
process. Should this work?
How does "He uses subversion to edit the permissible files and test
his changes on the dev machine" work? Maybe subversion allows him to
download copies of the permissible files, edit them locally, and
upload them back to the dev machine?
Should subversion be installed on the production machine too?
As far as why I'm doing this, the server-side code for my website is
in a series of many files. I'd like to hire a dev to work on some of
those files, but I don't want to give him read or write access to any
of the files besides the ones he is working on. The problem is, each
of the files can't be coded in isolation. He needs to be able to test
his changes in a running version of the website.
- Grant
Re: File access control
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Sep 28, 2011 at 10:41 PM, Grant <em...@gmail.com> wrote:
> I see that subversion supports path-based authorization:
>
> http://svnbook.red-bean.com/en/1.5/svn.serverconfig.pathbasedauthz.html
>
> Is there a way to do file-based authorization? Or maybe some sort of
> trickery to mimic file-based authorization? If not, can anyone think
> of a way to allow read/write access to only certain files in a working
> system? I could use chmod/chown but the files to which access is
> allowed will be changing pretty frequently so it would be nice to have
> accessible files defined in a list as part of the version control
> system, file transport mechanism, or anything else.
Files are paths too. The path-based authz applies to any path (folder
or file). For example:
[repos:/trunk/readme.txt]
@releng = rw
* = r
A rule like that works fine.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
RE: File access control
Posted by "Cooke, Mark" <ma...@siemens.com>.
> -----Original Message-----
> From: Grant [mailto:emailgrant@gmail.com]
> Sent: 29 September 2011 03:42
> To: users@subversion.apache.org
> Subject: File access control
>
> I see that subversion supports path-based authorization:
>
> http://svnbook.red-bean.com/en/1.5/svn.serverconfig.pathbasedauthz.html
>
> Is there a way to do file-based authorization? Or maybe some sort of
> trickery to mimic file-based authorization? If not, can anyone think
> of a way to allow read/write access to only certain files in a working
> system? I could use chmod/chown but the files to which access is
> allowed will be changing pretty frequently so it would be nice to have
> accessible files defined in a list as part of the version control
> system, file transport mechanism, or anything else.
>
I believe that the short answer is 'no'. There are strategies that could help depending on why you need the restrictions. However, chmod/chown is not one of them as it is not easy (nor recommended) to work out which objects in the fsfs data correspond to which files in the repo and each new revision will generate new fsfs elements (unless you use packing...)
Can you sketch out why you think you need to protect specific files?
~ mark c
Re: File access control
Posted by Ian Wild <ia...@wandisco.com>.
On Thu, Sep 29, 2011 at 1:34 PM, Prabhu Gnana Sundar <pr...@collab.net>wrote:
> **
> On Thursday 29 September 2011 05:10 PM, Ian Wild wrote:
>
> WANdisco offer a commercial product which does exactly this based on our
> proxy technology.
>
> http://www.wandisco.com/subversion/accesscontrol has more details - feel
> free to get in touch if you have any questions.
>
>
> I could nowhere see any information about *file-based* authorization in the
> link provided above.
>
I know it's not a detailed description, but as per the feature list on that
page: "Allows access control to be implemented at the SVNROOT, branch,
directory or *file* levels."
You can in fact specify regular expressions to determine patterns for your
rules, and we support wildcards etc through that mechanism so it's pretty
powereful.
> FYI:
> SubversionEdge has a simple and easy way of path-based authorization
> allowing the user to customize the permissions very easily.
>
>
Seeing as I'm in plug mode, so does uberSVN - http://www.ubersvn.com :-)
Best Wishes,
Ian
Ian Wild
WANdisco, Inc.
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com <http://www.ubersvn.com/>
Re: File access control
Posted by Prabhu Gnana Sundar <pr...@collab.net>.
On Thursday 29 September 2011 05:10 PM, Ian Wild wrote:
> On Thu, Sep 29, 2011 at 3:41 AM, Grant <emailgrant@gmail.com
> <ma...@gmail.com>> wrote:
>
> I see that subversion supports path-based authorization:
>
> http://svnbook.red-bean.com/en/1.5/svn.serverconfig.pathbasedauthz.html
>
> Is there a way to do file-based authorization?
>
>
> Hi Grant,
>
> WANdisco offer a commercial product which does exactly this based on
> our proxy technology.
>
> http://www.wandisco.com/subversion/accesscontrol has more details -
> feel free to get in touch if you have any questions.
>
> Best Wishes,
>
> Ian
I could nowhere see any information about *file-based* authorization in
the link provided above.
FYI:
SubversionEdge has a simple and easy way of path-based authorization
allowing the user to customize the permissions very easily.
--Prabhu
Re: File access control
Posted by Ian Wild <ia...@wandisco.com>.
On Thu, Sep 29, 2011 at 3:41 AM, Grant <em...@gmail.com> wrote:
> I see that subversion supports path-based authorization:
>
> http://svnbook.red-bean.com/en/1.5/svn.serverconfig.pathbasedauthz.html
>
> Is there a way to do file-based authorization?
Hi Grant,
WANdisco offer a commercial product which does exactly this based on our
proxy technology.
http://www.wandisco.com/subversion/accesscontrol has more details - feel
free to get in touch if you have any questions.
Best Wishes,
Ian
--
Ian Wild
WANdisco, Inc.
http://www.wandisco.com
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com <http://www.ubersvn.com/>