On Fri, 06 Jul 2007 01:45:03 +0200, Juliusz Chroboczek <[EMAIL PROTECTED]> wrote:
> Kevin: > > >> > The release repository is readable by all members of the project group, > >> > but only writeable by the release manager. That individual only pushes > >> > vetted patches into the release repository. > >> > > >> > In this dev/release scenario, if the patches exist on the same > >> > machine/filesystem, a get/pull/push will usually result in hard-links > >> > to the same file. However, owner, group, and permissions for a > >> > hard-linked file are global to all links, so it's impossible to have > >> > different settings for patches shared by both repositories unless > >> > --nolinks is used to ensure that each repository has its own copy of > >> > the patch. > > I don't get it. Darcs never modifies a patch file in place; what it > does is create a new one and update the index. Since neither the > directory nor the index file are shared by linking, I don't see how > there can be any issues in your example. Argh.. I think I've confused things. The example I provided (*not* the text above) was a theoretical (and perhaps improbable or even impossible) scenario in response to Eric's direct question, but that's not what --nolinks is for. The example I gave---and Eric's question---are more related to problems encountered during shared file permission mismatches or malicious user scenarios as you aptly described. Those are really special cases of the general shared file situation where the same shenanigans can be encountered. I actually *did* encounter a problem like Eric described in just this area some time back... as I recall it involved a restrictive umask that only gave write permissions to the darcs pusher and some inventory or tentative files. Unfortunately, I don't seem to be able to reproduce this scenario at the moment. ------ Putting the contentious issues aside, the text of my dev/release scenario that you included above is a better description of a situation where --nolinks is applicable. It's not so much of a case where malicious user activities are involved, but more that different repositories may have different access policies that can't be supported if the files are linked. Also consider that the "release" repository may be more publicly accessible than the "dev" repository, and that prudently the entire release repository might need to be read-only for everyone but the owner, even though it might not be an issue with respect to access by darcs itself. Veering back into the malicious cases: allowing write access to a patch file via an editor would allow a trojan horse to be inserted... a case which could be prevented by simply ensuring everything in the release repository is appropriately chmod'ed in which case it really shouldn't be linked to the original user's files. Personally, I find that darcs' ability to automatically create these links is a nice advantage, and it definitely should remain the default scenario. The --nolinks is only for the unusual case where a policy barrier needs to exist between repositories. -- -- Kevin Quick quick at org after sparq
pgpoMFlARUg39.pgp
Description: PGP signature
_______________________________________________ darcs-devel mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-devel
