Re: [PATCH] um: Accept /dev/fd/* uml block devices

[Gabriel de Perthuis <g2p.code@gmail.com>]

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.