> Non-root user can use root account connect to the remote host and mount
> some directory to local mountpoint through sshfs, but in this
> mountpoint, if the sticky bit of a directory is set, some operation (rm,
> mv, rmdir ...) to this directory will fail:
>
> [at remote host]
> root@...:~# mkdir /test
> root@...:~# chmod +t /test
>
> [at local host]
> $ sshfs root@... mnt
> $ mkdir mnt/a; rmdir mnt/a
> rmdir: mnt/a: Operation not permitted
>
> but, if I join these two commands to one line, rmir will success
> (occasionally still fail, but success in most time):
>
> $ sshfs root@... mnt; mkdir mnt/a; rmdir mnt/a
>
> moreover, add some delay between these two commands, rmdir fails again:
>
> $ sshfs root@... mnt; sleep 1; mkdir mnt/a; rmdir mnt/a
> rmdir: mnt/a: Operation not permitted
>
> I don't know whether the sticky-bit cause 'rmdir' to fail is a right
> behavior of sshfs or just a bug?
Well, it's definitely not the right behavior, but it's something to do
with how the kernel does the permission checking, so it's not really
an sshfs bug. You can actually work around this with the
"-oidmap=user" option.
> But at least, the inconsistency of the above tests should be a bug, am I
> right?
Hmm, yeah, that's a bug, and a rather weird one.
It doesn't actually depend on the time, but rather if there was any
lookup done on the root of the filesystem before the rmdir. Adding a
sleep possibly makes a difference because some daemon performs some
operation on the filesystem soon after it detects a new mount. You
can check this by starting sshfs with debugging enabled:
sshfs -d root@... mnt
I'm not going to hurry fixing this, because it doesn't seem to be a
very serious problem: it actually fixes the wrong behavior some of the
time.
But I will look into the problem of the sticky bit preventing
operations which should in fact be allowed.
Thanks,
Miklos
|
