linux-kernel - Re: [PATCH] SYSCTL: Fix sysctl breakage on systems with older glibc

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: <20091217164614.GI9804@basil.fritz.box>
Date:	Thu, 17 Dec 2009 17:46:14 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Andi Kleen <andi@...stfloor.org>, akpm@...ux-foundation.org,
	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] SYSCTL: Fix sysctl breakage on systems with older glibc

On Thu, Dec 17, 2009 at 07:07:54AM -0800, Eric W. Biederman wrote:
> reaction would be.  If it makes logging in and manually using the
> machine unbearable on systems with versions of glibc from days of
> yore, the level of logging is too high.

The reason I was slightly annoyed is because I flagged this 
during code review and it wasn't addressed before merging.

> 
> > I see this on a SUSE 10.0 system with glibc 2.3.5.
> > Don't warn for this common case.
> 
> Perhaps it is just my sample of the world but glibc < 2.5 isn't
> common, especially on machines that I am putting new kernels on.
> Equally machines with 3+ year old installs are rare.

Linux simply cannot abandon older user land. We still (near) 
fully support a.out executables, even on 64bit.

> 
> > Signed-off-by: Andi Kleen <ak@...ux.intel.com>
> >
> > diff -u linux-2.6.32-git12/kernel/sysctl_binary.c-o linux-2.6.32-git12/kernel/sysctl_binary.c
> > --- linux-2.6.32-git12/kernel/sysctl_binary.c-o	2009-12-16 12:15:52.000000000 +0100
> > +++ linux-2.6.32-git12/kernel/sysctl_binary.c	2009-12-16 12:14:58.000000000 +0100
> > @@ -1399,6 +1399,13 @@
> >  {
> >  	int i;
> >  
> > +	/* 
> > +	 * CTL_KERN/KERN_VERSION is used by older glibc and cannot 
> > +	 * ever go away.
> > +	 */
> The comment is wrong.  Older versions of glibc are perfectly happy
> getting -ENOSYS form sys_sysctl.

and it fills and fills and fills the kernel log. In practice
that's not usable.

> 
> > +	if (name[0] == CTL_KERN && name[1] == KERN_VERSION)
> > +		return;
> 
> If you make it printk_once for this case I think that strikes the right
> balance.  You won't be spammed to death by messages telling you about
> a silly old glibc, but you will be told.

It's not a "silly old glibc", it's a "perfectly functional old glibc"

-Andi
-- 
ak@...ux.intel.com -- Speaking for myself only.
--
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/