Re: [PATCH 1/5] fs: Verify access of user towards block device file when mounting

On Wed, Sep 30, 2015 at 07:42:15PM -0400, Mike Snitzer wrote: > On Wed, Sep 30 2015 at 4:15pm -0400, > Seth Forshee wrote: > > > When mounting a filesystem on a block device there is currently > > no verification that the user has appropriate access to the > > device

Re: [PATCH 1/5] fs: Verify access of user towards block device file when mounting

On Thu, Oct 01 2015 at 8:55am -0400, Seth Forshee wrote: > On Wed, Sep 30, 2015 at 07:42:15PM -0400, Mike Snitzer wrote: > > On Wed, Sep 30 2015 at 4:15pm -0400, > > Seth Forshee wrote: > > > > > When mounting a filesystem on a block

Re: [PATCH 1/5] fs: Verify access of user towards block device file when mounting

On Thu, Oct 01, 2015 at 10:40:08AM -0500, Eric W. Biederman wrote: > Seth Forshee writes: > > > When mounting a filesystem on a block device there is currently > > no verification that the user has appropriate access to the > > device file passed to mount. This has

Re: [PATCH 1/5] fs: Verify access of user towards block device file when mounting

Mike Snitzer writes: > What layer establishes access rights to historically root-only > priviledged block devices? Is it user namespaces? Block devices are weird. Mounts historically have not checked the permissions on the block devices because a mounter has CAP_SYS_ADMIN.

[PATCH v2 2/5] firmware: move completing fw into a helper

From: "Luis R. Rodriguez" This will be re-used later through a new extensible interface. Signed-off-by: Luis R. Rodriguez --- drivers/base/firmware_class.c | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git

[PATCH v2 0/5] firmware_class: extensible firmware API

From: "Luis R. Rodriguez" This v2 series pushes together a few simple code shifts me and David worked on with a new extensible firmware API. I have bundled these changes together as in my last v1 series [0] it was not clear why the first simple set of changes were being made,

[PATCH v2 1/5] firmware: generalize "firmware" as "system data" helpers

From: "Luis R. Rodriguez" Historically firmware_class code was added to help get device driver firmware binaries but these days request_firmware*() helpers are being repurposed for general system data needed by the kernel. Annotate this before we extend firmare_class more, as

[PATCH v2 5/5] firmware: add an extensible system data helpers

From: "Luis R. Rodriguez" The firmware API has evolved over the years slowly, as it grows we extend it by adding new routines or at times we extend existing routines with more or less arguments. This doesn't scale well, when new arguments are added to existing routines it means

[PATCH v2 4/5] firmware: generalize reading file contents as a helper

From: David Howells We'll want to reuse this same code later in order to read two separate types of file contents. This generalizes fw_read_file() for reading a file rebrands it as fw_read_file(). This caller lets us pegs arbitrary data onto the target buffer and size if the

Re: auditing kdbus service names

On Thursday, August 13, 2015 04:40:52 PM Steve Grubb wrote: > On Wednesday, August 12, 2015 10:48:10 PM Paul Moore wrote: > > On Wednesday, August 12, 2015 05:38:14 PM Steve Grubb wrote: > > > On Wednesday, August 12, 2015 08:40:34 AM Paul Moore wrote: > > > > Hello all, > > > > > > > > I'm

Re: [PATCH 1/5] fs: Verify access of user towards block device file when mounting

On Thu 01-10-15 10:55:50, Eric W. Biederman wrote: > The goal if possible is to run things like docker without needed to be > root or even more fun to run docker in a container, and in general > enable nested containers. Frankly at the filesystem side we are rather far from being able to safely