[mosh-devel] JuiceSSH STPClient Resuming

[Jérémie Courrèges-Anglas]

Hi,

Alex Elsayed <eternaleye at gmail.com> writes:

> Keith Winstein wrote:
>
>> Hi Tom,
>> (3) My guess of the way we would enforce this "use once" property is as
>> follows. To resume mosh-client from a saved state, JuiceSSH would give it
>> a filename where a different mosh-client had previously written out its
>> saved state. mosh-client will open() this filename, check that the open
>> succeeded, unlink() the filename, check that the unlink() succeeded, and
>> then read and use the saved state. We should check to make sure this
>> really does eliminate a race condition where two mosh-clients get started
>> at nearly the same time with the same stored state.
>
> I'd recommend using O_EXCL on the open.

Perhaps O_CREAT|O_EXCL would be good for state writing, but not so much
for reusing.  Perhaps were you thinking of O_EXLOCK|O_NONBLOCK?

> Even without it you ought to be fine 
> - then both open()'s could run before the unlink(), but the unlink should 
> fail in that case. The second check would catch it, but better to prevent 
> the other instance from getting an FD at all.

Indeed...,

> That eliminates the potential for a mistake in checking the return code.

Say you have three mosh-client processes: A and B are attempting to use
a session file, C is trying to write a session file with the same name
as A and B.

A opens "F" and succeeds
B opens "F" and succeeds
A unlinks "F" and succeeds
C dumps state to "F.new.XYZ"
C renames "F.new.XYZ" to "F" and succeeds
B unlinks "F" and succeeds

A and B use the same state and C's saved state is lost.  Something
stronger should be possible.

Let's say mosh would implement session storing in a generic way, easily
usable form the CLI.  Thinking out loud...

Storage a la Maildir:
---------------------
.mosh/
  sessions/
         tmp/
         new/
         cur/

State file creation:
--------------------
If a new session is successfully dumped in a file in .tmp/
then the file is renamed into .new/

State file reuse:
-----------------
If the chosen state file is successfully renamed from .new/ to .cur/
it is opened for reading and restoring session information.
If restoring session information succeeds, the file in .cur/ is
unlinked.

I did not think about this thoroughly, but this seems simpler than the
possible portability issues and corner cases of file locking.

Interface:
----------
$ mosh --state-file state-foo
would consider only the session stored in .mosh/sessions/new/state-foo

If the session name contains a slash, then it is taken as a full path to
a session file; in that case it is assumed that mosh-client should not
unlink the session file, since this would be useful for debugging and
regular session files are stored in a well-known place.

A --state-dir option could override .mosh/sessions/ in aliases and shell
wrappers.

I don't think I'd use that feature, but I'd probably implement it like
that.

Cheers,
-- 
jca | PGP: 0x06A11494 / 61DB D9A0 00A4 67CF 2A90  8961 6191 8FBF 06A1 1494