[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFxzZOL_TgQSvCUBNsm8OjR_UDHADL=bBeLe-xJ=3PsNhg@mail.gmail.com>
Date: Tue, 6 Dec 2011 17:11:59 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: John Johansen <john.johansen@...onical.com>,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [git pull] apparmor fix for __d_path() misuse
On Tue, Dec 6, 2011 at 4:52 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
>>
>> But why do you want that ancestor thing?
>
> Because the path is useless without some idea where it starts?
No.
You're thinking about this wrong, and you have gotten stuck thinking that way.
The "where it starts" doesn't help you in any way. It has absolutely
zero new information, apart from the "it's unreachable from your
current root" part.
> "It was /foo/bar/baz counting from some point; might have
> been global root, might have been any random mountpoint if we'd
> raced with umount and you've got no way to tell one from another"
> is not particulary useful in logs.
Umm. Think it through. NOBODY WILL EVER SEE ANYTHING ELSE *ANYWAY*.
There is no valid information in that "where it starts". There's
nothing more you can tell about it. So why return it?
The "it was /foo/bar/baz" part is undeniabty useful. People do
actually want that part, but they want it for printouts to the
sysadmin or the user, who will then go "Ahh, I see what's up, they're
in a chroot environment and they still have access to /foo/bar/baz
from outside".
But no possible user would ever actually care about that "ancestor"
thing. There is absolutely nothing useful you can say about it. It's
*some* kind of root, but that's just about all the relevant
information you'd ever want to know.
Equally importantly, no existing users actually use that information.
Sure, AppArmor looked at it, but it looked at it *WRONG*. What
AppArmor does doesn't actually make any sense to do.
So why make excuses for it? It's useless and unused information that
only complicates the interface. The only thing anybody *ever* actually
wants to know is that one single bit of information: "was it reachable
or not?"
Linus
--
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/
Powered by blists - more mailing lists