From: Nick Bowler <nbowler@elliptictech.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Kees Cook <kees@outflux.net>, "Theodore Ts'o" <tytso@mit.edu>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Linux 3.6
Date: Thu, 4 Oct 2012 09:35:04 -0400 [thread overview]
Message-ID: <20121004133504.GA5599@elliptictech.com> (raw)
In-Reply-To: <CA+55aFwXLXfAHHBEYYiz_4qjxWUpENECCZwFN_1gq+e48f+3Sw@mail.gmail.com>
On 2012-10-03 13:54 -0700, Linus Torvalds wrote:
> On Wed, Oct 3, 2012 at 1:49 PM, Kees Cook <kees@outflux.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/)
next prev parent reply other threads:[~2012-10-04 13:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-01 0:38 Linux 3.6 Linus Torvalds
2012-10-03 19:46 ` Nick Bowler
2012-10-03 20:05 ` Kees Cook
2012-10-03 20:29 ` Linus Torvalds
2012-10-03 20:41 ` Theodore Ts'o
2012-10-03 20:49 ` Kees Cook
2012-10-03 20:54 ` Linus Torvalds
2012-10-03 20:58 ` Kees Cook
2012-10-03 21:05 ` Alan Cox
2012-10-03 21:04 ` Kees Cook
2012-10-04 13:35 ` Nick Bowler [this message]
2012-10-04 15:49 ` Kees Cook
2012-10-04 16:03 ` Nick Bowler
2012-10-04 16:14 ` Kees Cook
2012-10-04 17:16 ` Nick Bowler
2012-10-04 21:30 ` Stefan Richter
2012-10-09 18:51 ` Nick Bowler
2012-10-03 20:49 ` Alan Cox
2012-10-03 22:23 ` Matthias Schniedermeyer
2012-10-03 23:58 ` Theodore Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121004133504.GA5599@elliptictech.com \
--to=nbowler@elliptictech.com \
--cc=kees@outflux.net \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).