Implement workaround to fake read/write open for read-only files

[lxp]

Some applications assume that privileged users can always override read-only permissions. With sshfs permissions are enforced by the server, which local privileged users cannot override.
This commit implements a workaround, which allows a read/write open of read-only files and lazily fail later on write.
One use-case of this workaround is eCryptfs, which always opens files read/write, even if a user only opens the file read-only.

ecryptfs on top of sshfs (workaround disabled):

$ ls -lah
ls: cannot access asdf: Permission denied
ls: cannot access asdf2: Permission denied
total 20K
drwxr-xr-x 1 user user 336 Apr 29 20:44 .
drwx-----x 1 user user 14K Apr 29 18:23 ..
?????????? ? ?    ?      ?            ? asdf
?????????? ? ?    ?      ?            ? asdf2
$ cat asdf
cat: asdf: Permission denied

[3372842.855588] Error opening lower file for lower_dentry [0xffff8804366f53c0] and lower_mnt [0xffff880437496020]; rc = [-13]
[3372842.855591] ecryptfs_i_size_read: Error attempting to initialize the lower file for the dentry with name [asdf]; rc = [-13]
[3372842.857222] Error opening lower file for lower_dentry [0xffff8804366f5900] and lower_mnt [0xffff880437496020]; rc = [-13]
[3372842.857224] ecryptfs_i_size_read: Error attempting to initialize the lower file for the dentry with name [asdf2]; rc = [-13]

ecryptfs on top of sshfs (workaround enabled):

$ ls -lah
total 44K
drwxr-xr-x 1 user user 336 Apr 29  2016 .
drwx-----x 1 user user 14K Apr 29 18:23 ..
-r--r--r-- 1 user user   4 Apr 29 23:02 asdf
-r--r--r-- 1 user user   5 Apr 29 20:44 asdf2
$ cat asdf
bla

[Nikratio]

Other applications may rely on the fact that open with O_RDWR fails if they don't have write permission, and then fail to handle the error on write, so I don't think this patch obviously improves the situation overall.

Do you have any source (POSIX, other Linux file systems) that behave similarly, i.e. delay the failure?

[lxp]

Yeah, I know that this dirty workaround can cause problems in certain scenarios.
Maybe it is really only helpful for eCryptfs, as it just does an open in kernel space with O_RDWR without checking the privileges.
At least in my configuration user-space applications are not affected, because the permissions are checked by the kernel in advance. Therefore, the situation that a read-only file is opened O_RDWR cannot happen in user-space.

My sshfs mount options:

$ cat /tmp/uidmap 
root:0
user:1000
$ cat /tmp/gidmap 
root:0
user:1000
$ sshfs user@remote: /mnt -o readdir_ino -o default_permissions -o allow_root -o big_writes -o idmap=file -o uidfile=/tmp/uidmap -o gidfile=/tmp/gidmap -o workaround=openrw -o reconnect

$ cat ~/openrw.c
#include <stdio.h>
#include <string.h>
#include <errno.h>

int main(void) {
    FILE *fp = fopen("asdf", "r+");
    if (fp == NULL) {
        printf("fopen: %s (%d)\n", strerror(errno), errno);
    }
}
$ gcc -o ~/openrw openrw.c

sshfs only (workaround enabled):

$ ls -lah
total 16K
drwxr-xr-x 1 user user 18 Apr 30  2016 .
dr-xr-xr-x 1 user user 64 Apr 30 14:18 ..
-r--r--r-- 1 user user  4 Apr 30  2016 asdf
-r--r--r-- 1 user user  5 Apr 30  2016 asdf2
$ ~/openrw 
fopen: Permission denied (13)
$ strace ~/openrw 
[...]
open("asdf", O_RDWR)                    = -1 EACCES (Permission denied)
[...]
$ cat asdf
bla

ecryptfs on top of sshfs (workaround enabled):

$ ls -lah
total 44K
drwxr-xr-x 1 user user 168 Apr 30 14:11 .
drwx-----x 1 user user 14K Mär 23 03:21 ..
-r--r--r-- 1 user user   4 Apr 30 14:11 asdf
-r--r--r-- 1 user user   5 Apr 30 14:11 asdf2
$ ~/openrw 
fopen: Permission denied (13)
$ strace ~/openrw 
[...]
open("asdf", O_RDWR)                    = -1 EACCES (Permission denied)
[...]
$ cat asdf
bla

[Nikratio]

Well, I guess it can't hurt to have it as an option. Could you please document the intended use (and the problems it can cause) though? I think README.md would be as good a place as any.

Also, please confirm (in a comment here) how you tested the pull request. (At minimum, that's autoreconf + configure + make + test with and without the option). Please mention ssh version.

[lxp]

I now moved away from eCryptfs, as it had other problems too. gocryptfs seems to be a way better alternative. It also works fine without this nasty sshfs workaround.
I don't really want to encourage people to use eCryptfs, especially when there are better alternatives available. Therefore, I wouldn't suggest to merge this pull request anymore. Please feel free to close it without merging.

[Nikratio]

closing as requested by submitter