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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <51F998EE.80208@gmail.com>
Date:	Thu, 01 Aug 2013 01:08:30 +0200
From:	Gabriel de Perthuis <g2p.code@...il.com>
To:	Richard Weinberger <richard@....at>
CC:	Jeff Dike <jdike@...toit.com>,
	user-mode-linux-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org
Subject: Re: [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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/