linux-kernel - Re: [PATCH] sysctl: Deprecate sys_sysctl in a user space visible fashion.

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:	Sun, 2 Sep 2007 06:05:00 -0500
From:	Rob Landley <rob@...dley.net>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Andi Kleen <andi@...stfloor.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sysctl: Deprecate sys_sysctl in a user space visible fashion.

On Sunday 02 September 2007 3:54:36 am H. Peter Anvin wrote:
> Rob Landley wrote:
> > On Saturday 01 September 2007 5:16:03 pm Andi Kleen wrote:
> >> Rob Landley <rob@...dley.net> writes:
> >>> A lot of embedded people like to configure /proc out of the kernel for
> >>> space reasons.  This would make that noticeably more painful.
> >>
> >> I had a patch for a sysctl_name(2) for this a long time ago.
> >> If it was a serious issue that could be reintroduced.
> >>
> >> BTW sysctl(2) only needs to be quiet for a single sysctl used
> >> by glibc.
> >>
> >> -Andi
> >
> > Yeah, I found it:
> > http://lkml.org/lkml/2003/7/10/345
> >
> > I think that if /proc/sys could be broken out as a separate filesystem,
> > and it was small and simple, the embedded people would probably be happy.
> >  Is your patch significantly smaller than such a filesystem would be? 
> > (Keeping in mind that the smallest thing you can do is run from
> > initramfs, and I think that's pulling in libfs already...)
>
> IMO, the big problem with /proc/sys (and, for that matter, /sys) is
> mainly that they have to live in the process namespace, which is highly
> awkward when one uses chroot().
>
> One way to solve *that* might be a system call to get a file descriptor
> to the root of sysfs or procsysfs which can be used with openat().  That
> has its own perils, of course...

If you're going to add a new api, you might as well go with the sysctl-by-name 
patch above, which looks reasonably small and simple to me from a very quick 
glance at a 2.6.0-era patch.

The advantage of breaking /proc/sys into a separate filesystem doesn't 
introduce a new API (although possibly a new line in the init scripts), so 
existing software doesn't have to change to use it, which is good.  It 
increases orthogonality and granularity, which embedded guys like me are 
generally in favor of. :)

On the other hand, if you're adding a system call to get a file descriptor to 
an arbitrary superblock you can then openat...  How do you refer to said 
superblock?  (Perhaps invent a "volume" syntax for all the superblocks, ala 
the amiga?  Do the /proc and /sys superblocks exist if nobody's mounted them 
yet?  Yes the open could instantiate them, but I'm wondering about the "list 
available filesystems that aren't in your namespace" and the security fun 
from that.  Presumably this is doable as non-root, because if you're root you 
can just mount /proc and /sys and go from there...)

You could also special case "mount" so that if you try to mount sysfs on /sys 
or proc on /proc (and they're not already mount points) you don't need to be 
root.  Seems a bit evil, though...

> 	-hpa

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.
-
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/