All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gabriel de Perthuis <g2p.code@gmail.com>
To: Richard Weinberger <richard@nod.at>
Cc: Jeff Dike <jdike@addtoit.com>,
	user-mode-linux-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] um: Accept /dev/fd/* uml block devices
Date: Sun, 28 Jul 2013 12:25:33 +0200	[thread overview]
Message-ID: <51F4F19D.3000300@gmail.com> (raw)
In-Reply-To: <51F4D275.70009@nod.at>

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.
--
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/


WARNING: multiple messages have this Message-ID (diff)
From: Gabriel de Perthuis <g2p.code@gmail.com>
To: Richard Weinberger <richard@nod.at>
Cc: Jeff Dike <jdike@addtoit.com>,
	user-mode-linux-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] um: Accept /dev/fd/* uml block devices
Date: Sun, 28 Jul 2013 12:25:33 +0200	[thread overview]
Message-ID: <51F4F19D.3000300@gmail.com> (raw)
In-Reply-To: <51F4D275.70009@nod.at>

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.

  reply	other threads:[~2013-07-28 10:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-27 15:23 [PATCH] um: Accept /dev/fd/* uml block devices Gabriel de Perthuis
2013-07-28  8:12 ` Richard Weinberger
2013-07-28 10:25   ` Gabriel de Perthuis [this message]
2013-07-28 10:25     ` Gabriel de Perthuis
2013-07-31 23:08     ` Gabriel de Perthuis
2013-07-31 23:08       ` Gabriel de Perthuis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51F4F19D.3000300@gmail.com \
    --to=g2p.code@gmail.com \
    --cc=jdike@addtoit.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=richard@nod.at \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.