tomb r/w lock about tomb HOT 19 CLOSED

wow, that would be very cool! however, I won't put it in my "priority todolist" for tomb. If you want it quickly, you can assign this item to yourself ;)

from tomb.

On Sat, 23 Jul 2011, boyska wrote:

wow, that would be very cool! however, I won't put it in my
"priority todolist" for tomb. If you want it quickly, you can assign
this item to yourself ;)

[METHOD] sure. just consider those issues I open as something I'm
planning to do myself and, in the "worst" case If anyone gets on the
task, I'd like to interact.

I love smelling my own brainfarts, so to say.

from tomb.

But there is the -o flag for this, isn't it ?
The lock file is useless imho.

from tomb.

-o is useful if you already know that you have to mount it readonly. But how can you know if someone else is using it r/w ? this is what the lockfile is for

from tomb.

On Tue, 26 Jul 2011, boyska wrote:

-o is useful if you already know that you have to mount it
readonly. But how can you know if someone else is using it r/w ?
this is what the lockfile is for

yep. left to decide what's the default.

i think the lockfile should be created by default,
providing an option to deactivate it

from tomb.

should the lockfile be INSIDE the tomb? or outside it?
And, most important of all, have you checked if mounting a tomb on r/w on a pc, and on readonly on another means having "sharing" ? I don't really think so, but I could be wrong :)

from tomb.

lockfile should be inside the tomb (if detected on mount then do -o remount,ro )

it kind of means sharing, at least one could monitor changes in read-only.

from tomb.

I think it's NOT possible to have a safe lock INSIDE THE TOMB (doing it inside means you already have r/w access).
nignux is working on a simple implementation of a lock OUTSIDE the tomb: this is easy, but of course is not-so-desirable.

from tomb.

so far tomb has no external configuration files at all. making this external to the tomb would add the task of having a config directory, but I'm not in favour of that since it harms deniability.

why is not possible to have a safe lock inside the tomb? simply tomb will -o remount,ro before the user has a chance to write anything.

from tomb.

about external: this does not need a config directory, just a file being put aside the tomb. So if the tomb is in /path/to/my.tomb , the lock is in /path/to/my.tomb.lock.

about lock inside the tomb:
well, jaromil, if you manage to do it, kudos to you :)
but keep in mind that something like

if ! [[ -e lockfile ]]; then # it does not exist
    touch lockfile
fi

is NOT a safe lock.
To have safe locking there are special algorithms, OR simple utilities like flock or fcntl.
Which, however, make the file empty when locking it (this means they are only good to be put in an EXTERNAL file)

from tomb.

1. having the file outside the tomb would make it difficult or impossible to manage on remote FS (who owns it?)
2. having the file inside the tomb means, as @boyska noted, that you already have rw access to it. Or that someone else had access to it, and still has access. Or that someone had access to it, and the network connection broke, and the lock file is stale. How to deal with that?

from tomb.

Moreover, if a tomb is mounted rw by default, then switched to ro, it feels less safe than if it's ro by default, and rw on-demand. For personal (non-shared) tombs, rw makes sense...

Maybe we could have a .mounts/ directory where each current mount is documented, and only one can have rw at a time. That way, if I mount a shared tomb, and @jaromil already mounted it and has rw access, I can't, but I can still request rw mode, so that jaromil's mount can have a chance to say: "I lost connection to the mount, so it must be a stale file, and you can have write access" using a watch on .mounts/

The idea is to get around the stale files, and allow people accessing the same tomb to be aware of each other's presence/need.

from tomb.

@hellekin why "having the file outside the tomb would make it difficult or impossible to manage on remote FS" ? if you can use a remote tomb, you can use a remote lockfile.

I don't see how the .mounts/ method could work; the problem is that, if you have this sequence:

• A mounts the tomb
• B mounts the tomb
• A "register" himelf inside .mounts/
• A and B does whatever edit in the tomb
• B won't see A's registration, nor any of A modifications of the filesystem
• A won't see B's edits.

And anyway, if just one rw-mount can be allowed, why shall we use a directory? using a lockfile is just the same.

I think we should just face the fact that a tomb cannot be used by two peer's together. We can just manage a safe way of locking it.

from tomb.

A and B have access to host H, where the tomb is.

• if the lock is out of the tomb, what are the permissions?

Your scenario sounds wrong to me, because the tomb is remotely mounted, so the changes are available to all users who mount it, including of course the internal lock file. I don't imagine that a user would "register", but that the program would drop a file there, so that all people who mount the tomb will have access to it (most probably read access, so I guess .mounts/ would have the sticky bit.)

Then, B would try writing some file and get "this tomb is read-only, notifying other users", and the program drops a file in .mounts. As both users watch that directory (tomb is doing it for them, A receives a notification: "B is asking for the write lock [Accept|Cancel]", etc.

That said, such a mechanism could work with a single lock file. The problem is what happens when A has the write lock, and loses the connection, leaving a stale file?

from tomb.

On Sat, Feb 16, 2013 at 10:32:31AM -0800, hellekin wrote:

A and B have access to host H, where the tomb is.

• if the lock is out of the tomb, what are the permissions?

well, just assure that they are the same of the tomb itself. So who has access
to the tomb, also can access the lockfile

Your scenario sounds wrong to me, because the tomb is remotely mounted, so
the changes are available to all users who mount it, including of course the
internal lock file.

ext[234] is not meant to be used like this. Indeed, I did tried this. I tried
both using a tomb from 2 computers, and using a simple ext2 image with no luks
around from 2 different computers. It didn't work, giving all that sorts of
strangeness that I explained.
(Actually, there were a bit of randomness in this; sometimes the files
appeared, sometimes they don't. This doesn't change much: ext doesn't seem to
like that someone else changes his data without him knowing. It probably has to
do with caching, don't really know)

If you did experiments showing the contrary, please explain how you did. Maybe
there is some strange option like -o nonexclusive

I don't imagine that a user would "register", but that
the program would drop a file there, so that all people who mount the tomb
will have access to it (most probably read access, so I guess .mounts/ would
have the sticky bit.)

uh, yes, that's what I called registration: putting a file inside .mounts/ to
tell "hey, I mounted it".

That said, such a mechanism could work with a single lock file. The problem
is what happens when A has the write lock, and loses the connection, leaving
a stale file?

obeying to lock is not mandatory ;)
I mean: we're not using hard-lock (they are bad!). We are using soft-lock.
if ! option_is_set --ignore-locks; then wait_lock; fi
If you feel confident that there really is noone, just use --ignore-locks.
Death of a locking process is always a problem, in every locking scenario you
can imagine.

boyska

from tomb.

Hmmm, I've been using several shared encrypted partitions but never experienced any issues. Maybe we didn't try hard enough to make it fail.

ext[234] supports the --bind option that allows to remount part of an already mounted partition. That could be used, if you trust the remote machine. But then it's a different use-case, distinct from what Tomb is supposed to do.

from tomb.

Guys, I'm unsure, really. This feature is not making it into release 1.3.

from tomb.

Agreed, let's have a nice personal setup, and think about sharing later. For a personal setup, it makes sense to open read-write by default, don't you think?

from tomb.

yes, sure. defaults will stay as they are.

from tomb.