brz and symlinks inside branch checkout

[Aaron Bentley]

I don't know whether Bazaar is usable for your use case or not.  I don't
think that the specific thing you tried to do should work, but I don't know
why you were trying to do that specific thing and whether there are
alternatives that would work better with Bazaar.

For example, perhaps you could store everything on your encryptfs
filesystem and then symlink or bind-mount some things back into the
non-encrypted area.  It sounds like the way you currently have it, you're
trying to store files from an encrypted filesystem into a Bazaar repository
on a non-encrypted filesystem.  If that's the case, the files might as well
be on a non-encrypted filesystem, too.  If some of the files you want
commit deserve encryption, then the repository should also be on an
encrypted filesystem.

In terms of controlling the working tree, it's about a different issue than
yours that Jelmer brought up.  pad.lv/411068 is about mount points
specifically.  Bazaar needs to control the working tree so that commands
like revert, merge, pull, shelve, etc. can work.  "bzr revert -r 0" should
remove all versioned files, directories and symlinks from the working
tree.  "bzr revert" should restore them.  But it can't restore a directory
that's also a mountpoint.  It doesn't have the data or the privileges to do
that.  When you do "rm -r some-directory-inside-the-working-tree", you're
doing an operation that "bzr revert" can reverse.  When you change a
mountpoint, you're not.  Of course, it's only the *versioned* files that
Bazaar needs to control.  It will happily ignore (and preserve) any
non-versioned files.

What you're trying to do is write to files outside the working tree, and
Bazaar should not allow that.  It's a distributed version control system,
and it would be a security risk if, by making a working tree from someone
else's branch, I could overwrite my ~/.bashrc or ~/.profile, etc.  The risk
of external software is supposed to be when you run it, not when you simply
get a copy of the source code.  This is no different from tar, or any other
archiving software.  Only the subdirectory that you extract the archive
into should be affected.

An overlay filesystem would be better than changing bazaar to use
copy+delete(i.e. shutil.move) to emulate a rename in one way: the rename is
supposed to be an atomic operation that either succeeds or fails, with no
chance of partially moving the files.  Copy+delete cannot make that
guarantee of an atomic operation, but an overlay filesystem could.

Aaron

On Sat, Jun 2, 2018 at 3:59 AM Martin Steigerwald <martin at lichtvoll.de>
wrote:

> Hi Aaron.
>
> Aaron Bentley - 01.06.18, 16:17:
> > Bazaar is perfectly happy with symlinks, but if you create a symlink
> > to a directory, you should not "bzr add" any of the files in that
> > directory. (In fact, I thought we had good check against that).
> > Bazaar should not be manipulating files outside its working tree.
> > Bazaar is supposed to be in control of the contents of the working
> > tree, so whatever files Bazaar is manipulating should actually be in
> > the working tree.
> >
> > os.replace is not a fix for pad.lv/411068: "The operation may fail if
> > src and dst are on different filesystems".  Even if it behaved more
> > like shutil.move, I disagree that 411068 should be "fixed" by using
> > shutil.move or the like.  If you've mounted a directory into your
> > working tree, you've taken control away from Bazaar because it can't
> > reproduce that state.
>
> Do you want to tell me that my use case is nothing Bazaar is usable for?
>
> Why is Bazaar in need to control the working tree? It *never* controls
> it. It never is the only software access to a working tree is restricted
> to. I do a rm -r some-directory-inside-the-working-tree or something
> else does it and the stuff is gone. To me that is quite similar to the
> rare case that the Private directory would not be there. It is mounted
> on login by pam-ecryptfs. So it is usually just always there when I use
> brz. And if it is not there… hey thats my responsibility to be careful
> in that case.
>
> I genuinely believe that software should be behave as intelligent as
> required, but not more intelligent like in "I do know better what to use
> me for than you do.". However if there is a solid reason why brz cannot
> work in such a use case or it would be too cumbersone and error prone to
> add such functionality, then I´d be willing to reconsider my use case.
> But an artificially limitation IMHO is not it. Of course it is not on me
> to require that anyone implements it for me. So unless someone does or I
> provide a patch I am stuck with the current situation anyway. I could
> probably do some kind of union / overlay thing to make brz believe that
> it is working on just one filesystem, while it is not.
>
> […]
> --
> Martin
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20180602/9abc8ddc/attachment.html>