linux-kernel - [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-next>] [day] [month] [year] [list]

Date:	Thu, 19 Nov 2015 23:26:35 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	linux-fsdevel@...r.kernel.org
Cc:	linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-security-module@...r.kernel.org, miklos@...redi.hu,
	dhowells@...hat.com
Subject: [RFC] readlink()-related oddities

	I'd been looking through ->readlink() callers, and there are
several areas where behaviour looks wrong.

1) atime updates, according to POSIX, should happen in case of success.
For example, giving readlink(2) an unmapped buffer should _not_ touch
atime.  Neither should calling readlink(2) in case if ->readlink() method
returns e.g. -EIO or -ENOMEM.  We do atime update in those cases.  Looks
like a bug and unless there's a good reason to keep that behaviour, I'd
rather have it do what POSIX says.

The question of which ->readlink() callers should bother with atime is
interesting as well:
	* readlink(2) and nfsd_readlink() are touching atime of the
symlink in question.  Fair enough.
	* ecryptfs_readlink_lower() calls ->readlink() on the underlying
filesystem inode and does *not* do anything to atime there.  Also makes sense -
one of the callers (->getattr()) certainly does not want timestamps modified,
the other two will have atime of ecryptfs symlink touched, which will propagate
to underlying fs.
	* overlayfs copyup does not touch atime of the underlying object.
Also fine - the whole reason we are doing the copyup is that the layer it
was in is not to be modified in any way.
	* overlayfs ->readlink(), OTOH, *does* attempt to touch atime
of the symlink we end up reading.  Looks bogus, especially since
symlink _traversal_ does no such thing.  Am I missing something subtle here?
Miklos?

2) LSM, with its usual stellar consistency, has a hook stuck into
readlink(2), but not into nfsd_readlink().  Could the esteemed Linux S&M folks
decide if that's right?

3) normally, readlink(2) fails for non-symlinks.  Moreover, according to
POSIX it should do so (with -EINVAL).  There is a pathological case when
it succeeds for a directory, though.  Namely, one of the kinds of AFS
"mountpoints".  stat(2) reports those as directories, stepping into them
leads to automounting a directory there (why do we have ->open() for
them, BTW?)  How the hell is userland supposed to guess to call readlink(2)
on those suckers to get the information of what'll get automounted there if
we step upon them?  And could we please get rid of that kludge?  David?
--
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/