Hello, > > While it is nice that you have concerns about my security in case I should > > have to deal with malicious servers, > > I would prefer to have a choice. Maybe some setting wich allows me, based > > on the server URL (or if that's too > > complicated for a start), to allow ../ in local externals paths or disallow > > this. With such a setting, SVN would > > seamlessly allow us to use our current directory layout while maintaining > > the benefits of atimic checkins.
> Excuse me, but given the layout requirements you seek, can you get away with > symlinks? I'm not sure symlinks under XP are powerfull enough and the use of them is not easy enough for my colloeagues. I'd really prefer a externals based solution. > There are too many cases where non-root users have access to Subversion > repositories for repositories that > get run by, and manipulated by, the root user. The possibility of escalation > attacks for *other* environments seems very large. That is why I suggested a setting controlling this. The default could be to disallow it. You can misuse nearly everything! So nearly everything in the world should be disallowed. I also suggested that limiting this relative addressing to a single level in the hierarchy (means only ../ instead of ../../) would be sufficient for must users and still keeping a good deal of the security. And if you could enable this for individual "domains" only one can still limit it for local servers only. If properly implemented it will only do good for those needing it and no harm (unless misconfigured, but that can be said for most configuration options in most software...) => I'll request that on the developer mailing list as suggested. Best regards Markus Humm EB-EV Entwicklung Elektronik ebm-papst Mulfingen GmbH & Co. KG Bachmühle 2 74673 Mulfingen Phone: +49 (7938) 81 531 Fax: +49 (7938) 81 9531 markus.h...@de.ebmpapst.com <mailto:markus.h...@de.ebmpapst.com> http://www.ebmpapst.com <http://www.ebmpapst.com/> GreenTech - <C:\Tmp\\attc7eb.gif> Ein Zeichen, mit dem wir Zeichen setzen. A symbol that defines standards. ________________________________ Von: Nico Kadel-Garcia [mailto:nka...@gmail.com] Gesendet: Freitag, 2. März 2012 13:13 An: Humm, Markus Cc: Daniel Shahaf; users@subversion.apache.org Betreff: Re: Feature request: allow for relative working copy paths in svn:externals definition On Fri, Mar 2, 2012 at 6:13 AM, Humm, Markus <markus.h...@de.ebmpapst.com> wrote: Hello, thanks for your answer. While it is nice that you have concerns about my security in case I should have to deal with malicious servers, I would prefer to have a choice. Maybe some setting wich allows me, based on the server URL (or if that's too complicated for a start), to allow ../ in local externals paths or disallow this. With such a setting, SVN would seamlessly allow us to use our current directory layout while maintaining the benefits of atimic checkins. Excuse me, but given the layout requirements you seek, can you get away with symlinks? There are too many cases where non-root users have access to Subversion repositories for repositories that get run by, and manipulated by, the root user. The possibility of escalation attacks for *other* environments seems very large. A colleague of mine who uses a similiar directory layout and currently uses CVS and would have to switch when our SVN rollout happens now claimed that CVS supports this way of working (directory structure). If I'm not mistaken SVN uses the claim "CVS done right". So it should support this, as this is a legitimate directory structure And imposes no security problems in secure environments (eg. Our campus LAN with out local SVN server I administer). Then write your own patch to disable the checks. For general deployment, I think it's begging for escalation attacks. What do I need to do to get this feature? Where do I need to lobby for it? I'm an old user, not a core developer, but this would seem to be a good place for general discussion I can see the escalation attacks in a more general environment, myself: I see too many places in environments where I work that an *accidental* such use could cause endless havoc by pre-populating a system directory, such as, say, /etc/nagios. ebm-papst Mulfingen GmbH & Co. KG Sitz der Gesellschaft: Bachmuehle 2, D-74673 Mulfingen Kommanditgesellschaft Sitz Mulfingen: Amtsgericht Stuttgart HRA 590344 Komplementaer: Elektrobau Mulfingen GmbH, Sitz Mulfingen, Amtsgericht Stuttgart HRB 590142 Geschaeftsfuehrung: Hans-Jochen Beilke (Vorsitzender), Thomas Borst, Hans Peter Fuchs, Dr. Bruno Lindl, Thomas Wagner
