linux-kernel - Re: [PATCH] driver core: add uid and gid to devtmpfs

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:	Mon, 08 Apr 2013 13:14:13 -0500
From:	Rob Landley <rob@...dley.net>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	linux-kernel@...r.kernel.org, Kay Sievers <kay@...y.org>,
	Al Viro <viro@...IV.linux.org.uk>
Subject: Re: [PATCH] driver core: add uid and gid to devtmpfs

On 04/06/2013 11:56:00 AM, Greg KH wrote:
> From: Kay Sievers <kay@...y.org>
> 
> Some drivers want to tell userspace what uid and gid should be used  
> for
> their device nodes, so allow that information to percolate through the
> driver core to userspace in order to make this happen.  This means  
> that
> some systems (i.e.  Android and friends) will not need to even run a
> udev-like daemon for their device node manager and can just rely in
> devtmpfs fully, reducing their footprint even more.

Wasn't the entire "devfsd" saga because this was policy and didn't  
belong in kernel space? I guess it's not policy if Android wants it?  
It's just The One True Way?

Or is this because containers allow UID/GID to be redefined, and thus  
imposing magic values on userspace can now be mapped away or something?

(I studied this fairly closely before writing busybox mdev way back,  
and I'm really not following the change in rationale here.)

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