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
| ||
|
Date: Thu, 19 Nov 2015 19:09:20 -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 6:57 PM, Al Viro <viro@...iv.linux.org.uk> wrote: > > How would those tools know that this particular pathname _is_ a magical > symlink? Like maybe just the AFS management tools? By design you'd only run them on the mountpoint in question. Not everything has to be "generic". Sometimes its' good enough to just have the ability to get the work done. Now, if it turns out that others also want to do this, maybe somebody decides "let's add flag -V to 'ls', which forces a 'readlink()' on all the targets, whether links or not, and shows the information". I could imagine other special files having "a single line of information about the file" that they'd expose with readlink(). Who knows? So there is *potential* for just making it generic, but that doesn't mean that it necessarily has to act that way. 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