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]
Message-ID: <ac3eb2510909180450x19e1272dq6f742f49bc56d4a2@mail.gmail.com>
Date:	Fri, 18 Sep 2009 13:50:29 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Greg KH <greg@...ah.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [bug] /etc/profile: line 30: /dev/null: Permission denied (Was: 
	Re: [PATCH] Remove broken by design and by implementation devtmpfs 
	maintenance disaster)

On Fri, Sep 18, 2009 at 08:02, Greg KH <greg@...ah.com> wrote:
>> Here is a quick hack to allow subsystems to provide a mode for their
>> devices. It uses the callback that can provide custom non-default device
>> names. Ingo, maybe you can give it a try?
>>
>> To see how it works, it currently includes access to: null, zero, full,
>> random, urandom, tty, ptmx. Also the USB /dev nodes have the same
>> permissions as the USB /proc nodes always had. That's basically what
>> udev does today for non-root users.
>
> Ick, I don't think we should do something like this, it starts putting
> the mode policy back into the kernel.

Yeah, we should not go too far here. I don't mind having the few 0666
well-defined special nodes though.

>  What's next, owner and group?  :)

Udev does not set a owner ever I think, uid is always root. Group
name/number mapping is usually not known by the kernel, so we should
be safe here for the common systems. :)

The Android guys though have the group ids in the kernel as part of
their platform spec. They expressed interest to be able to manage all
this with their platform code. So we might just want to provide the
needed hooks for people with these very specific setups, to plug into
it.

> I think the udev version in older Fedora releases can't handle this
> kernel option, which is fine, just don't enable it.  Newer versions can
> handle it, right?

Yes, they should work fine. I guess even the old versions will run
fine, it's more that Ingo did not run any udev, I expect.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ