Date: Fri, 14 Aug 2015 13:01:16 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 161424] [nullfs] __getcwd() calls fail when used on nullfs mount Message-ID: <bug-161424-3630-E5v0SHhZ2O@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-161424-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-161424-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=161424 Konstantin Belousov <kib@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kib@FreeBSD.org --- Comment #10 from Konstantin Belousov <kib@FreeBSD.org> --- (In reply to fullermd from comment #9) What you described is the expected behaviour, it is just a situation that it always happens for nullfs, but only sporadically for other filesystems. More precisely, nullfs does not use namecache for good reasons (we cannot provide cache consistency between nullfs entries and lower filesystems without some drastic measures). If a filesystem uses namecache, then getcwd call first tries to resolve the path using namecache, and only when the cache failed to provide an entry, it falls down to read the ".." directory and searching the child entry name by inode number. So typically for fs like ufs or zfs, the reading of ".." does not happen. On the other hand, since nullfs does not use namecache, ".." is always scanned and there the directory permissions starts to play. So the fix, if we ever would change the observed behaviour, is to make getcwd to honor the directory permissions even when the request is satisfied by the namecache, making failure deterministic. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-161424-3630-E5v0SHhZ2O>