> > OK, open is out. However other operations (stat, unlink, chmod etc)
> > are always without side effects on "normal" filesystems. However on
> > FUSE they are very much unsafe (can block, not do what was instructed
> > and return success, etc).
>
> What about tricking a setuid program to stat into /auto (/mnt/auto,
> /misc, whatever it is called)? then the automounter will act upon a root
> request with again possibly unwanted side effects. See how careful a
> setuid/full-root program must be in handling userdata including pathnames?
I don't see why /auto is special. It's basically a userspace
filesystem too, but that's not what is specaial about FUSE. It's the
fact the it's a userspace filesystem controlled by an _ordinary user_.
> FUSE suddenly makes this more obvious but it is not new.
I believe it _is_ something new. If it were not, then your arguments
would be bulletproof. As it is, I think you miss the point that the
side effect is actually in the hands of the user invoking the suid
program, instead of something external.
> > > including changing the ptraceability test by a signal test and including
> > > the (IMHO) required emptyness of the mount stub?
> >
> > It's been thrown out for the reason, that it's unacceptable if suid
> > programs see a different namespace as non-suid.
>
> You mean root versus non-root. or user versus other user I assume. Because
> the euid (fsuid) is what matters.
Yes.
> But then: this _is_ already the case for NFS when squash_root is in effect
> (what about kerberos et.al?). So there are several reasons to consider
> FUSE a nonlocal fs instead of a local one so nothing new there. FUSE could
> be used to implement a usable (not perfect) userspace NFS/ftp client.
Yes. In fact even if the check were left out of the kernel, the
userspace filesystem could still return different data/error based on
fsuid/fsgid/pid.
So what's so controversial about it? I really fail to understand...
> To require an empty stub to mount FUSE upon makes the whole picture
> cleaner: users are only able to extend the namespace _leaf_ nodes for
> themselves and processes they can send signals to: setuid programs
> which do not fully become root. The existing namespace [nodes] remains
> unchanged for everyone.
It's not as simple. A filesystem can be mounted many times (either
with mount --bind, or just by mounting the same device on multiple
mountpoints). In this case you can't ensure, that a mountpoint will
remain a leaf node after being mounted on.
Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |