Re: [RFC] readlink()-related oddities

From: Linus Torvalds <torvalds@linux-foundation.org>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	LSM List <linux-security-module@vger.kernel.org>,
	Miklos Szeredi <miklos@szeredi.hu>,
	David Howells <dhowells@redhat.com>
Subject: Re: [RFC] readlink()-related oddities
Date: Thu, 19 Nov 2015 19:16:32 -0800	[thread overview]
Message-ID: <CA+55aFy=__75U59zj0G7fqU5AjZO_FEEE=bqt7bk+4S41NLHgg@mail.gmail.com> (raw)
In-Reply-To: <CA+55aFyWTDZxATj=WbX_X-Eb=mCO9s=ULZdPmyQRXNGQOgbBZw@mail.gmail.com>

On Thu, Nov 19, 2015 at 7:09 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> So there is *potential* for just making it generic, but that doesn't
> mean that it necessarily has to act that way.

.. it's not necessarily just readlink() either. I still think it might
be a perfectly fine idea to allow non-directories to act as
directories in some case (by exposing "readdir" and "lookup").

But readdir() really doesn't sound horrible either. how about unix
domain sockets (or named pipes) giving their link information when you
do readdir() on them?

Quite frankly, I think allowing those kinds of unified interfaces is
better than the current situation where you have to use a
"getpeername()" system call etc. If it's a filesystem object, why not
allow filesystem operations to work on it?

We expose some things in /proc as symlinks things that actually would
work better as non-symlinks, exactly *because* we want to expose not
just the end result of what they point to, but also a *description* of
what they point to. So we have those odd "pseudo-symlinks" in /proc
that don't actually really do a pathname walk on the symlink content
they expose, but still *look* like symlinks just because readdir() is
such a useful thing to have.

No wonder other users have wanted to use it.

                    Linus