linux-kernel - [bug] /etc/profile: line 30: /dev/null: Permission denied (Was: Re: [PATCH] Remove broken by design and by implementation devtmpfs maintenance disaster)

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: <20090917185306.GA28635@elte.hu>
Date:	Thu, 17 Sep 2009 20:53:06 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Greg KH <greg@...ah.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Kay Sievers <kay.sievers@...y.org>
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@...ssion.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
--
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/