From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161336AbbKSX0j (ORCPT ); Thu, 19 Nov 2015 18:26:39 -0500 Received: from zeniv.linux.org.uk ([195.92.253.2]:43343 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934635AbbKSX0h (ORCPT ); Thu, 19 Nov 2015 18:26:37 -0500 Date: Thu, 19 Nov 2015 23:26:35 +0000 From: Al Viro To: linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Linus Torvalds , linux-security-module@vger.kernel.org, miklos@szeredi.hu, dhowells@redhat.com Subject: [RFC] readlink()-related oddities Message-ID: <20151119232635.GI22011@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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?