linux-kernel - Re: [RFC] readlink()-related oddities

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: <CA+55aFy=__75U59zj0G7fqU5AjZO_FEEE=bqt7bk+4S41NLHgg@mail.gmail.com>
Date:	Thu, 19 Nov 2015 19:16:32 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	LSM List <linux-security-module@...r.kernel.org>,
	Miklos Szeredi <miklos@...redi.hu>,
	David Howells <dhowells@...hat.com>
Subject: Re: [RFC] readlink()-related oddities

On Thu, Nov 19, 2015 at 7:09 PM, Linus Torvalds
<torvalds@...ux-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
--
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/