Miklos Szeredi wrote:
quoted text
> On Fri, 29 Aug 2008, Tejun Heo wrote:
>> I'm not worried about the client accessing wrong memory regions or even
>> corrupting it.  It's pointless to try to protect against that.  From the
>> calling process's POV, it runs the same risk whether it calls an
>> in-kernel ioctl or a CUSE one and FUSE already has sufficient protection
>> against allowing unprivileged FS implementation to serve other users.
> 
> Yes and no.  Fuse allows this protection to be relaxed
> (-oallow_other), because it does provide quite good privilege
> separation.  This ioctl thing breaks that, so we should disable ioctls
> with 'allow_other' or require the filesystem to be privileged.  But
> the latter is not easy because mount(2) is always privileged, we don't
> know if the process calling fusermount was privileged or not.
> 
> So, your current patch actually _introduces_ a security vulnerability
> with the 'allow_other' mount option.

Ah.. right.  allow_other.  Yeah, restricting ioctl implementation only
to root or !allow_other sounds like a good idea.

quoted text
>> What I'm worried about is the possibility of CUSE client being able to
>> break out of that privilege protection which is currently ensured by the
>> kernel.
> 
> What do you call client?  If you mean the app using the char dev, then
> I don't see how it could break out of any protection.

I first used 'server' for userland [FC]USE server but then I noticed
there were places in FUSE they were referred as clients so now I use
'client' for those and call the app using the FUSE fs the 'caller'.
What are the established terms?

Anyways, doing it directly from the server (or is it client) opens up a
lot of new possibilities to screw up and I'd really much prefer staying
in similar ballpark with other operations.  Maybe we can restrict it to
two stages (query size & transfer) and linear consecutive ranges but
then again adding retry doesn't contribute too much to the complexity.
Oh.. and BTW, the in-ioctl length coding is not used universally, so it
can't be depended upon.

quoted text
>>  Also, what about containers?  How would it work then?
> 
> Dunno.  Isn't there some transformation of pids going on, so that the
> global namespace can access pids in all containers but under a
> different alias?  I do hope somethinig like this works, otherwise it's
> not only fuse that will break.

I'm not sure either.  Any idea who we should be asking about it?

Thanks.

-- 
tejun
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/