linux-kernel - Re: [PATCH 0/3] vfs: plug some holes involving LAST_BIND symlinks and file bind mounts (try #5)

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]

Date:	Tue, 24 Nov 2009 12:53:09 +0100
From:	Miklos Szeredi <miklos@...redi.hu>
To:	Jeff Layton <jlayton@...hat.com>
CC:	jamie@...reable.org, ebiederm@...ssion.com,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	pavel@....cz, miklos@...redi.hu, viro@...IV.linux.org.uk
Subject: Re: [PATCH 0/3] vfs: plug some holes involving LAST_BIND symlinks
 and file bind mounts (try #5)

On Tue, 24 Nov 2009, Jeff Layton wrote:
> Since it's clear that these symlinks do need to have special semantics,
> perhaps the approach you suggest would be the best thing. I'll have to
> think about it a bit more.

open() is not the only thing you need to think about.  Anything that
checks read or write permission on the inode (truncate, utimes,
*xattr) would have to be changed to respect the open mode.

See, this is not just about hacking the proc follow_symlink code to
check some lookup intent.  It's about changing the permission checking
mechanism for theses beasts.  And since the permission checking is
inode based, this is not at all trivial to do.

I still believe leaving the current semantics and documenting them is
the best option.

Thanks,
Miklos
--
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/