Messages in this thread | | | From | (Eric W. Biederman) | Date | Fri, 23 May 2014 15:23:50 -0700 | Subject | Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces |
| |
Serge Hallyn <serge.hallyn@ubuntu.com> writes:
> Quoting Eric W. Biederman (ebiederm@xmission.com): >> >> >> >> Ultimately the technical challenge is how do we create a block device >> >> that is safe for a user who does not have any capabilities to use, and >> >> what can we do with that block device to make it useful. >> > >> > Yes, and I'd like to get started solving those challenges. But I also >> > don't think we can address these two points (support partition blkdevs, >> > help prevent more priveleged users from using a namespace's loop >> > devices) sufficiently while having an implementation completely >> > contained within the loop driver as Greg is requesting. >> >> My key take away from the conversation is that we should reduce the >> scope of what is being done to something that makes sense and the >> propblems are immediately visible. >> >> Part of me would like to suggest that fuse and it's ability to imitate >> device nodes might be a more appropriate solution, to something that > > Do you have a link to more info on this? Some googling got me to an > interesting but old thread on CUSE, but nothing specifically about fuse > doing this.
CUSE is probably what I was thinking of. It is all part of the fuse code base in the kernel. And now that I am reminded it is called CUSE I go Duh that is a character device...
Fuse and everything it can do is definitely the filesystem I would like to see most have the audits to be enabled in user namespace. Fuse was built to be sufficiently paranoid to allow this and so it should not take a lot to take fuse the rest of the way.
>> just needs block device access and nothing else. >> >> For purposes of discussion let's call it unprivloopfs. That can reuse >> code from the loop device or not as appropriate. Not supporting >> paritioning I think is a very reasonable first step until it is shown >> that we can make good use of partitioning support, and there are not >> better ways of solving the problem. >> >> I expect the most productive thing to talk about is what is your >> immediate goal? Mounting a filesystem? Building an iso? > > For me it would be taking an iso and making some changes to it to > localize it (i.e. take an install iso and add preseed file). > > Now of course in the end there is no reason why we can't do all of > this with a new suite of libraries which simply uses read/write with > knowledge of the fs layouts to parse and modify the backing files. > My concern there is that duplicating all of the fs code seems unlikely > to improve the soundness of either implementation. Perhaps we can > autogenerate this from the kernel source? Does fuse already do > something like that?
I am not aware of that. But I have not worked extensively with fuse.
I do agree that finding a way to perform a read-only mount of an ISO by an unprivielged user is a very interesting use case. Given it's interchange medium nature isofs should be as hardened as human possible, and that is likely easier with a read-only filesystem. And at less than 4000 lines of code isofs is auditable.
So as a target for unprivileged mounts of a block device isofs looks like a good place to start.
Eric
| |