lkml.org 
[lkml]   [2009]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subject[bug] /etc/profile: line 30: /dev/null: Permission denied (Was: Re: [PATCH] Remove broken by design and by implementation devtmpfs maintenance disaster)

* Eric W. Biederman <ebiederm@xmission.com> wrote:

> Greg this code does not live up to the standards you have repeatedly
> asserted are required for accepting core kernel code. Neither you nor
> Kay show any interest in fixing even the most trivial of bugs. Must
> less discuss alternate solutions to the problem.

on a tangential note - i have no opinion yet in this discussion, but i
found no pull request email on lkml and wanted to report a devtmpfs bug:

I've reproduced a bug with the following .config options:

CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y

/dev/null and /dev/zero are not read/writable to ordinary users,
breaking normal bootup and login:

earth4:~/tip> m
PTY allocation request failed on channel 0
/etc/profile: line 30: /dev/null: Permission denied

/etc/profile.d/colorls.sh: line 3: /dev/null: Permission denied
/etc/profile.d/colorls.sh: line 4: /dev/null:
Permission denied

/etc/profile.d/vim.sh: line 5: /dev/null: Permission denied
Connection to m
closed by remote host.
Connection to m closed.

Regarding the wish to have in-kernel code: another solution which i have
not seen mentioned would be to move udev into tools/udev/ instead. That
would give a single, coherent user-space kernel-space combo.

The concept certainly works great for tools/perf/.

The system boots up fine with devtmpfs disabled:

earth4:~/tip> m
Last login: Fri Sep 18 02:48:19 2009 from sirius
mercury:~>

Ingo


\
 
 \ /
  Last update: 2009-09-17 20:57    [W:0.202 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site