linux-kernel - Re: [PATCH] driver-core: devtmpfs - driver core maintained /dev tmpfs

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] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 1 May 2009 19:02:41 -0700
From:	Brian Swetland <swetland@...gle.com>
To:	Kay Sievers <kay.sievers@...y.org>
Cc:	Greg KH <greg@...ah.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Jan Blunck <jblunck@...e.de>
Subject: Re: [PATCH] driver-core: devtmpfs - driver core maintained /dev tmpfs

On Fri, May 1, 2009 at 6:48 PM, Kay Sievers <kay.sievers@...y.org> wrote:
> On Sat, May 2, 2009 at 03:24, Brian Swetland <swetland@...gle.com> wrote:
>> It's always struck me as odd that sysfs couldn't provide device node
>> access, given that there's already an entity exposed for everything
>> (or nearly everything).
>
> You really want to be able to run grep-like stuff in sysfs, which
> would do horrible things with device nodes. Also it does not support
> extended attributes, not access control lists, ..., all stuff we need
> for device nodes. You also want userspace to have control over device
> nodes, and possibly mangle them, regardless what the kernel exports,
> that's why it's a tmpfs and not part of sysfs.

That makes sense.

>> It seems weird to have to have an agent in
>> userspace to create another hierarchy in addition to what the kernel
>> already maintains.
>
> Well, until just recently, there was no sane definition how device
> nodes are names and layouted, every system did it differently, some
> even tried to keep the totally useless devfs naming scheme alive. Now
> that we managed to define a common default setup, which almost
> everybody ships it, it makes it possible to add the few needed rules.

That's good news -- I wasn't sure if there was still variety in layout
policies that required somehow supporting multiple different ones.

>> I guess the really tricky bit is how to deal with
>> permissions/ownership sanely.
>
> Simple permissions would be possible without too much hassle, but uid
> gid ownership, I can't see how the kernel could do that.

Yeah, I don't see any easy solution there.  Which means we end up
having to have some userspace agent responsible for arranging
permissions as devices are published.

>> I suspect there's no easy way to do
>> something that "just works" for even the majority of userspace
>> environments.
>
> It will work just fine for root environments, what's missing without
> userspace support is if you need to grant specific users access to
> devices.
>
>> Most of the ugly in the microudev thing in our init
>> comes from having to do something about permissions.
>>
>> I would love to have a way for the kernel to do something like devfs
>> (it'd let me kill some ugly userspace code on my side)....
>
> How are permissions defined in your environment? What's the set of
> permissions you need to apply?

In our world we use groups to provide access to specific classes of
hardware resources (audio, video, display, dsp, etc) and processes
that have the appropriate permissions are arranged to run with
necessary additional groups for the hardware they need to access.
Very little of the system ever runs as root -- most runs as a per-app
or per-service untrusted user with permissions granted via group
membership.

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