linux-kernel - Re: Linux 3.6

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: <20121004133504.GA5599@elliptictech.com>
Date:	Thu, 4 Oct 2012 09:35:04 -0400
From:	Nick Bowler <nbowler@...iptictech.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Kees Cook <kees@...flux.net>, Theodore Ts'o <tytso@....edu>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 3.6

On 2012-10-03 13:54 -0700, Linus Torvalds wrote:
> On Wed, Oct 3, 2012 at 1:49 PM, Kees Cook <kees@...flux.net> wrote:
> > I think the benefits of this being on by default outweigh glitches
> > like this. Based on Nick's email, it looks like a directory tree of his
> > own creation.
> 
> I agree that *one* report like this doesn't necessarily mean that we
> need to turn it off, if Nick is happy to just fix up his script and
> it's all local.
> 
> However, I suspect we'll see more. And once that happens, we're not
> going to keep a default that breaks peoples old scripts, and we're
> going to have to rely on distributions (or users) explicitly setting
> it.

Yes, it is a directory of my own creation, intended as a place for users
(read: me) to stick stuff on the local disk as opposed to on NFS.  It's
pretty trivial for me to fixup everything to not need this symlink
anymore (and I suspect it is the only offender); I just created the
symlink in the first place so that I wouldn't have to change anything
else.

(While on /this/ machine I created the directory, I have used shared lab
machines with a similar setup).

The thing that bothers me most about all this is that it's basically
impossible to see why things are failing without digging through the git
tree or posting to the mailing list (or recalling earlier mailing list
discussions about the restriction, as I vaguely do now).  You just
suddenly get "permission denied" errors when all the permissions
involved look fine.  As far as I know, the owner, group and mode of
symlinks have always been completely meaningless.  Upgrade to 3.6, and
they're suddenly meaningful in extremely non-obvious ways.

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

--
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/