Le 28/07/2013 12:25, Gabriel de Perthuis a écrit : > Le dim. 28 juil. 2013 10:12:37 CEST, Richard Weinberger a écrit : >> Am 27.07.2013 17:23, schrieb Gabriel de Perthuis: >>> Useful for >>> * limiting privileges >>> * opening block devices O_EXCL >> >> So, the goal of this patch is to allow passing a file descriptor >> number as block device instead of a file? > > Yes. It turns out it already works, but not after dropping privileges. > >> I assume you have already a wrapper around UML which exec()'s it such that >> it can reuse a fd? > > Yes, vido: https://github.com/g2p/vido > > Here's the relevant commit: > https://github.com/g2p/vido/commit/42d4b86eab13d90ee63138b73146485dc4e47ec6 > >>> Use dup to work around the fact /proc/self/fd >>> can't be opened after dropping privileges. >>> This proc behaviour doesn't match TLPI and might be a bug. >>> >>> Qemu has a slightly more complex fdset approach >>> that provides fds with different access permissions. >> >> I really don't like that you patch os_open_file(), this is a >> generic function. > > The justification was that it unbreaks open("/dev/fd") to be more like > standards suggest, but I can see how that makes it a special case. > >> What about this one? >> Allow ubda= (and all other UML block device kernel parameters) to >> accept arguments like file:/foo/bar and fd:N. >> Where N is a number and file: is default such that we do not break >> old kernels. > > Okay, I'll add a prefix. Maybe file:// + /abs/path | rel/path > since that's already standard.
I've done some work on this approach, but it turns out to clash with the cow syntax; in ubd0=file:cowfile, ":" is a path separator. Changing things in ubd_kern.c is also more intrusive, even with the limited goal of making it work for plain, non-cow files I need to duplicate a few code paths to work with fds instead of names and the diffstat is getting large. Because of that I'd like to come back to /dev/fd/<n>. It does overload the generic file opener, but does so consistently, so that you can think of /dev/fd as a virtual filesystem. The (arguably broken) /proc/self/fd behaviour remains available through the /proc path. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
