New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mosh-server does not keep eCryptfs home directory mounted (needs PAM session?) #529

Open
rhazegh opened this Issue May 25, 2014 · 9 comments

Comments

Projects
None yet
5 participants
@rhazegh

rhazegh commented May 25, 2014

Ubuntu 12.04 with the latest updates, Vim version 7.3.429
Mosh server (Ubuntu, amd64), Version: 1.2.4-0931precise1

Mosh client (osx): 1.2.4 (installed via brew)

  • When I ssh to the Ubuntu box, I can run vim and quit vim with no problem.
  • But, when I mosh to the Ubuntu box and run vim, I get this message when I try to quit vim: E138: Can't write viminfo file /home/my_account/.viminfo!

Any idea what is going on here?

@andersk

This comment has been minimized.

Show comment
Hide comment
@andersk

andersk May 25, 2014

Member

Is your home directory on a networked filesystem (AFS, NFS, etc.) that requires authentication? Also, did you check that .viminfo didn't accidentally become owned by root (try ls -l .viminfo)?

Member

andersk commented May 25, 2014

Is your home directory on a networked filesystem (AFS, NFS, etc.) that requires authentication? Also, did you check that .viminfo didn't accidentally become owned by root (try ls -l .viminfo)?

@rhazegh

This comment has been minimized.

Show comment
Hide comment
@rhazegh

rhazegh May 26, 2014

Is your home directory on a networked filesystem (AFS, NFS, etc.) that requires authentication?

No. It's on a local hard disk. The home folder is encrypted with eCryptfs.

Also, did you check that .viminfo didn't accidentally become owned by root (try ls -l .viminfo)?

The file is not owned by root:

-rw------- 1 my_account my_account 625 May 25 17:06 .viminfo

If the problem was file permission, I suppose the same error should have happened when I used ssh.

rhazegh commented May 26, 2014

Is your home directory on a networked filesystem (AFS, NFS, etc.) that requires authentication?

No. It's on a local hard disk. The home folder is encrypted with eCryptfs.

Also, did you check that .viminfo didn't accidentally become owned by root (try ls -l .viminfo)?

The file is not owned by root:

-rw------- 1 my_account my_account 625 May 25 17:06 .viminfo

If the problem was file permission, I suppose the same error should have happened when I used ssh.

@rhazegh

This comment has been minimized.

Show comment
Hide comment
@rhazegh

rhazegh May 26, 2014

I found the issue:

  • When I ssh to the Ubuntu box, the encrypted home folder gets mounted automatically.
  • But when I mosh to the Ubuntu box, the encrypted home folder is not mounted automatically. If I mount it with ecryptfs-mount-private the problem goes away.

rhazegh commented May 26, 2014

I found the issue:

  • When I ssh to the Ubuntu box, the encrypted home folder gets mounted automatically.
  • But when I mosh to the Ubuntu box, the encrypted home folder is not mounted automatically. If I mount it with ecryptfs-mount-private the problem goes away.

@rhazegh rhazegh closed this May 26, 2014

@andersk

This comment has been minimized.

Show comment
Hide comment
@andersk

andersk May 26, 2014

Member

Ah, eCryptfs. What actually happens is that pam_ecryptfs maintains a session counter (/dev/shm/ecryptfs-$USER-Private) that is incremented on PAM login and decremented on PAM logout. The temporary SSH session that mosh uses to launch the remote mosh-server causes a PAM login followed immediately by a PAM logout, so the counter reaches zero and the encrypted folder is unmounted immediately.

I don’t think that running a PAM session as a non-root user is a supported operation, so mosh-server itself cannot cause a PAM login. But this is a problem we’d like to solve, even if we don’t currently have a good solution, so I’ll reopen this in case someone has ideas.

Member

andersk commented May 26, 2014

Ah, eCryptfs. What actually happens is that pam_ecryptfs maintains a session counter (/dev/shm/ecryptfs-$USER-Private) that is incremented on PAM login and decremented on PAM logout. The temporary SSH session that mosh uses to launch the remote mosh-server causes a PAM login followed immediately by a PAM logout, so the counter reaches zero and the encrypted folder is unmounted immediately.

I don’t think that running a PAM session as a non-root user is a supported operation, so mosh-server itself cannot cause a PAM login. But this is a problem we’d like to solve, even if we don’t currently have a good solution, so I’ll reopen this in case someone has ideas.

@andersk andersk reopened this May 26, 2014

@andersk andersk changed the title from I get "E138: Can't write viminfo file" error only when connected via mosh to mosh-server does not keep eCryptfs home directory mounted (needs PAM session?) May 26, 2014

@andersk

This comment has been minimized.

Show comment
Hide comment
@andersk

andersk May 26, 2014

Member

(As an example of the kind of amazing horrible things that go spectacularly wrong if you try to run a PAM session as non-root, I just filed LP #1323421 “pam_ecryptfs returns twice from fork in error conditions”.)

Member

andersk commented May 26, 2014

(As an example of the kind of amazing horrible things that go spectacularly wrong if you try to run a PAM session as non-root, I just filed LP #1323421 “pam_ecryptfs returns twice from fork in error conditions”.)

@diepes

This comment has been minimized.

Show comment
Hide comment
@diepes

diepes Nov 4, 2014

Prevent auto unmount by deleting ~/.ecryptfs/auto-umount

diepes commented Nov 4, 2014

Prevent auto unmount by deleting ~/.ecryptfs/auto-umount

@mek-apelsin

This comment has been minimized.

Show comment
Hide comment
@mek-apelsin

mek-apelsin Feb 28, 2015

While running mosh 1.2.4a:
local$ mosh remote
remote(encrypted)$ cat /dev/shm/ecryptfs-$USER-Private
0
remote(encrypted)$ ecryptfs-mount-private
FAIL
remote$ cat /dev/shm/ecryptfs-$USER-Private
1
remote(encrypted)$ ^D
local$ ssh remote cat /dev/shm/ecryptfs-$USER-Private
2 (WTF 1)
local$ mosh remote
remote(unencrypted)$ (WTF2)
remote$ cat /dev/shm/ecryptfs-$USER-Private
1 (WTF 3)
remote(encrypted)$ ^D
local$ ssh remote cat /dev/shm/ecryptfs-$USER-Private
2 (WTF 4)

This is with a totally empty but existing.profile, both in the encrypted and the unencrypted home-folder on remote. Why does the counter add one when disconnecting and subtract one when connecting?

mek-apelsin commented Feb 28, 2015

While running mosh 1.2.4a:
local$ mosh remote
remote(encrypted)$ cat /dev/shm/ecryptfs-$USER-Private
0
remote(encrypted)$ ecryptfs-mount-private
FAIL
remote$ cat /dev/shm/ecryptfs-$USER-Private
1
remote(encrypted)$ ^D
local$ ssh remote cat /dev/shm/ecryptfs-$USER-Private
2 (WTF 1)
local$ mosh remote
remote(unencrypted)$ (WTF2)
remote$ cat /dev/shm/ecryptfs-$USER-Private
1 (WTF 3)
remote(encrypted)$ ^D
local$ ssh remote cat /dev/shm/ecryptfs-$USER-Private
2 (WTF 4)

This is with a totally empty but existing.profile, both in the encrypted and the unencrypted home-folder on remote. Why does the counter add one when disconnecting and subtract one when connecting?

@andersk

This comment has been minimized.

Show comment
Hide comment
@andersk

andersk Mar 1, 2015

Member

That’s not what’s going on. ssh increments the count by 1 when opening the session, and decrements the count by 1 when closing the session. When you ran ssh remote cat /dev/shm/ecryptfs-$USER-Private, the cat ran between this increment and decrement pair. mosh uses a short-lived ssh session to create the session, which increments and then immediately decrements the count, leaving it net unchanged.

Member

andersk commented Mar 1, 2015

That’s not what’s going on. ssh increments the count by 1 when opening the session, and decrements the count by 1 when closing the session. When you ran ssh remote cat /dev/shm/ecryptfs-$USER-Private, the cat ran between this increment and decrement pair. mosh uses a short-lived ssh session to create the session, which increments and then immediately decrements the count, leaving it net unchanged.

@cgull

This comment has been minimized.

Show comment
Hide comment
@cgull

cgull Mar 31, 2016

Member

We'd still like to find a better fix for this, but tonight @eminence mentioned a half-decent workaround on #mosh: ssh localhost upon connecting to the remote host. mosh remote-host-name ssh localhost will often work as well.

This won't work all the time, but when it does you still get most of the benefits of mosh.

Member

cgull commented Mar 31, 2016

We'd still like to find a better fix for this, but tonight @eminence mentioned a half-decent workaround on #mosh: ssh localhost upon connecting to the remote host. mosh remote-host-name ssh localhost will often work as well.

This won't work all the time, but when it does you still get most of the benefits of mosh.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment