lkml.org 
[lkml]   [2013]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] um: Accept /dev/fd/* uml block devices
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 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/

\
 
 \ /
  Last update: 2013-08-01 01:41    [W:0.059 / U:19.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site