[sshfs] Issue mounting SSHFS'd home folder during login

[IT D. <it...@om...>]

I've been using sshfs controlled by pam_mount to mount user's remote home
folder to the local home folder on diskless terminals.  This was working
fine using the version of ssh and sshfs included in Ubuntu 11.10, however
using the version in 14.04 (sshfs 2.5, OpenSSH 6.6p1) the mount process
locks up.

Activating debug, and testing using the following test pattern it locks up
after printing "executing <ssh> ...."

# Test reproduction #
Here's how I was able to test the situation, eliminating pam_mount and many
other variables: (Caveat, I'm typing these commands into this email by hand
- if there's typos, please correct!)
1. Create a test user (skip if you already have one) - for this procedure
I'll call the username 'test'
2. Create the a user with the same name on a server.
3. Remove the test user's home folder: `rm -r /home/test`
4. Create an empty home folder, thus simulating what pam_mount does
automatically: `mkdir /home/test; chown test:test /home/test`
5. Log in as the test user: `su - test`
6. Mount the user's home folder: `sshfs test@myserver:/home/test /home/test
-o workaround=rename,nonempty,allow_other,nodev,nosuid`
7. Observe to see if the mount completes.

The process hangs at step 7, thankfully a CTRL-C cancels it testing this
way.  If pam_mount calls it during login...  that's another story.

Note that after pressing CTL-C to cancel the process, you must execute
`umount /home/test` to test again.

# Thoughts #
After some time of tweaking around with debug flags and other settings and
observing the resulting behavior, it looks to me like the following is
happening:
1. The mounting process gets some form of write lock on /home/test.
2. SSHFS then calls the SSH client with the SFTP subprotocol flag.
3. The SSH client then tries to get a readlock on (or even just read) some
file in the current user's home folder: /home/test

Of course, the writelock prevents all reads and readlocks in that
mountpoint.

I hope this was a clear enough description of the problem.  Thankfully it
seems to constantly reproduce, indicating that there doesn't seem to be any
race condition, just a sequence problem.

Ricky Curtice
IT Guy
Omega Diamond, Inc.