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 dcchap...@acm.org
Chapman Consulting -- San Jose, CA
