mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kay Sievers <kay.sievers@vrfy.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ingo Molnar <mingo@elte.hu>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Greg KH <greg@kroah.com>,
	linux-kernel@vger.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)
Date: Fri, 18 Sep 2009 00:26:14 +0200	[thread overview]
Message-ID: <ac3eb2510909171526ga51ecfag74af1a34a0437189@mail.gmail.com> (raw)
In-Reply-To: <alpine.LFD.2.01.0909171322210.4950@localhost.localdomain>

On Thu, Sep 17, 2009 at 22:26, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, 17 Sep 2009, Kay Sievers wrote:

> That may be "not supported", but the point is, we want to make the kernel
> be as self-sufficient as possible, and the whole _point_ of this devtmpfs
> seemed to be to increase self-sufficiency rather than decrease it by
> requiring 'udev' to have run very very early.

Yes, that's the point. We could try to push the limit even higher and
try to run without udev. A few embedded and linux-on-cell-phone people
already asked for the same thing.

> If you have udev running really early, then what's the point of devtmpfs?
> You might as well just have udev and tmpfs.

It still simplifies the bootstrapping of an empty mounted /dev tmpfs,
and makes the node creation synchronous, unlike udev. It also makes
rescue very easy and reliable. It solves a bunch of problems, at least
for system-level privileged tasks, like module loading with immediate
device access after modprobe returns.

> So I suspect /dev/null and /dev/zero should be special - just make them
> have 0666 permissions. Because they really _are_ special, and no other
> permissions ever make sense for them.

That's true. I guess there are a few more devices that need special
permissions. We could make that happen, so people could probably run a
system without udev on top, at least in a controlled environment. For
distros it's not that interesting, they will need all the hotplug
handling, and all the stuff that plugs into udev's event mechanisms.
We only thought about bootup and root users for now, but that could be
changed, if it makes things easier.

Kay

  parent reply	other threads:[~2009-09-17 22:26 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-17  8:23 [PATCH] Remove broken by design and by implementation devtmpfs maintenance disaster Eric W. Biederman
2009-09-17 12:03 ` Kay Sievers
2009-09-17 13:13   ` Alan Cox
2009-09-17 16:35     ` Scott James Remnant
2009-09-17 17:47       ` Arjan van de Ven
2009-09-17 18:59         ` Scott James Remnant
2009-09-17 19:11           ` Arjan van de Ven
2009-09-18 12:57           ` Eric W. Biederman
2009-09-18 13:16   ` Eric W. Biederman
2009-09-18 13:54   ` Eric W. Biederman
2009-09-18 14:09     ` Arjan van de Ven
2009-09-18 14:11       ` Kay Sievers
2009-09-18 14:25         ` Arjan van de Ven
2009-09-18 14:32           ` Kay Sievers
2009-09-18 14:43             ` Arjan van de Ven
2009-09-18 14:58               ` Kay Sievers
2009-09-18 15:13                 ` Arjan van de Ven
2009-09-18 15:32                   ` Kay Sievers
2009-09-18 19:33                     ` Eric W. Biederman
2009-09-18 14:42       ` Eric W. Biederman
2009-09-17 12:57 ` Greg KH
2009-09-17 13:05   ` Alan Cox
2009-09-17 13:29     ` Greg KH
2009-09-17 15:43       ` Alan Cox
2009-09-18  6:03         ` Greg KH
2009-09-18  9:25           ` Alan Cox
2009-09-18 15:05             ` Greg KH
2009-09-17 17:29   ` Eric W. Biederman
2009-09-17 18:53     ` [bug] /etc/profile: line 30: /dev/null: Permission denied (Was: Re: [PATCH] Remove broken by design and by implementation devtmpfs maintenance disaster) Ingo Molnar
2009-09-17 19:18       ` Kay Sievers
2009-09-17 20:26         ` Linus Torvalds
2009-09-17 20:31           ` Ingo Molnar
2009-09-18  5:58             ` Greg KH
2009-09-25 20:49               ` Pavel Machek
2009-09-27 22:52                 ` Greg KH
2009-09-17 22:26           ` Kay Sievers [this message]
2009-09-17 22:41             ` Alan Cox
2009-09-18  0:18             ` Linus Torvalds
2009-09-18  1:50               ` Kay Sievers
2009-09-18  6:02                 ` Greg KH
2009-09-18 11:50                   ` Kay Sievers
2009-09-18 14:18                   ` Linus Torvalds
2009-09-18 15:05                     ` Greg KH
2009-09-18 15:37                       ` Kay Sievers
2009-09-18 19:35                         ` Kay Sievers
2009-09-18 19:41                           ` Linus Torvalds
2009-09-18 19:50                           ` Ingo Molnar
2009-09-20  1:43                             ` Dave Airlie
2009-09-20 15:08                               ` Greg KH
2009-09-21  2:58                                 ` Dave Airlie
     [not found]                                 ` <ac3eb2510909200912o76e0d4e4l2dcaf352fe6b4e19@mail.gmail.com>
     [not found]                                   ` <ac3eb2510909200914g1ed6a47cydc0edec6fff96ef4@mail.gmail.com>
2009-09-21  2:59                                     ` Dave Airlie
2009-10-20 20:32                                       ` Scott James Remnant
2009-09-20 17:33                               ` Ingo Molnar
2009-09-18 20:58                 ` [bug] /etc/profile: line 30: /dev/null: Permission denied Eric W. Biederman
2009-09-18 21:09                   ` Linus Torvalds
2009-09-18 21:19                     ` Kay Sievers
2009-09-18 22:06                       ` Linus Torvalds
2009-09-18 21:31                   ` Kay Sievers
2009-09-18 22:03                     ` Eric W. Biederman
2009-09-18  5:54     ` [PATCH] Remove broken by design and by implementation devtmpfs maintenance disaster Greg KH
2009-09-18 12:24       ` Eric W. Biederman

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=ac3eb2510909171526ga51ecfag74af1a34a0437189@mail.gmail.com \
    --to=kay.sievers@vrfy.org \
    --cc=ebiederm@xmission.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=torvalds@linux-foundation.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®