Comment 1 Mark Linimon 2011-10-10 06:10:06 UTC

Responsible Changed
From-To: freebsd-bugs->freebsd-fs

Over to maintainer(s).

Hi,

are you able to reproduce this problem on FreeBSD 9.0?

Thanks,
-- 
Mateusz Guzik <mjguzik gmail.com>

On 06/11/2012 08:37 PM, Mateusz Guzik wrote:
> Hi,
> 
> are you able to reproduce this problem on FreeBSD 9.0?
I cannot reproduce it right now but I do not have clean 9.0 release
available.

-- 
VZ

I have exactly the same problem in FreeBSD 9.1-RELEASE (almost, it runs
on AWS so some minor patches).

I have an ZFS pool, and nullfs mounted it. I wrote a simple C program
which exhibits the problem:

#include <stdio.h>
#include <errno.h>
#include <unistd.h>

int main () {
	void *r;
	char c[1024];
	r = getcwd(c, 1024);
	printf ("r = %p, errno = %i\n", r, errno);
	printf ("dir = %s\n", c);

}


Result:

r = 0x0, errno = 13
dir =

Very annoying, as I have my home directories on /u1/home and remount
them on /home to avoid having to rename a bunch of stuff.

All the best,

Berend.

Can report this is still a problem on FreeBSD 10.

Comment 6 Andriy Gapon 2014-02-19 10:30:51 UTC

Can you provide all the steps required to reproduce the problem?
The exact commands you execute to do mounting, to change to a directory, etc.

I can not reproduce the problem by just nullfs mounting one directory over
another, cd-ing into the mount and running your program.

-- 
Andriy Gapon

Comment 7 Jilles Tjoelker 2015-04-27 15:21:18 UTC

*** Bug 121898 has been marked as a duplicate of this bug. ***

Still happens on latest 10.1

To repeat you need to be an unprivileged user. As root I get:

    r = 0x7fffffffe690, errno = 2
    dir = /home/berend/sites/staging.xplainhosting.com

As user berend I get:

    r = 0x0, errno = 13
    dir = 

My setup: zpool name u1.

Mounted as:

    /u1/home on /home (nullfs, local)

Users reside in a postgresql which is made available via pam_pgsql and nss-pgsql.conf files. The latter appears to be inconsequential, because when a user is simply listed in /etc/passwd get the same error. For example this user:

    www:*:80:80::0:0:World Wide Web Owner:/nonexistent:/bin/sh

I get:

    $ pwd
    /home/test
    # su www
    $ /tmp/a.out
    r = 0x0, errno = 13
    dir = 
    $ whoami
    www

Hope this helps.

I've just run into what looks like this (after lots of tracking and puzzled-looking) myself on a stable/10 system (in a jail, but it happens outside of jails too).

What's happening is that, when you're on a nullfs, if you don't have read permissions to all the directories in the path up to the root, it blows up, whereas on a regular FS, it does just fine.

e.g., I have a "/thome/matt/tmp/wt".  /thome and /thome/matt are root:wheel 751; the tmp/wt dirs are 755.  I use www as a convenient user, changing its shell to /bin/sh.

% (cd /thome/matt/tmp/wt ; su www -c /bin/pwd)
/thome/matt/tmp/wt

Yep, that's what it should get.  So then I null mount /thome off into /tmp:

% mount_nullfs /thome /tmp/th/

Then:

% ( cd /tmp/th/matt/tmp/wt ; su www -c /bin/pwd )
pwd: .: Permission denied

If I chmod 755 /thome and /thome/matt, then

% ( cd /tmp/th/matt/tmp/wt ; su www -c /bin/pwd )
/tmp/th/matt/tmp/wt

Comment 10 Konstantin Belousov 2015-08-14 13:01:16 UTC

(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.

Comment 11 Eitan Adler 2018-05-28 19:44:45 UTC

batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.