NetBSD Problem Report #36963

From martin@duskware.de  Mon Sep 10 12:32:13 2007
Return-Path: <martin@duskware.de>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id D74AA63B89F
	for <gnats-bugs@gnats.netbsd.org>; Mon, 10 Sep 2007 12:32:13 +0000 (UTC)
Message-Id: <20070910115001.4979E63B89F@narn.NetBSD.org>
Date: Mon, 10 Sep 2007 11:50:01 +0000 (UTC)
From: jan.m.danielsson@gmail.com
Reply-To: jan.m.danielsson@gmail.com
To: netbsd-bugs-owner@NetBSD.org
Subject: NetBSD complains about permissions problems
X-Send-Pr-Version: www-1.0

>Number:         36963
>Category:       kern
>Synopsis:       NetBSD complains about permissions problems
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Sep 10 12:35:00 +0000 2007
>Last-Modified:  Sun Mar 15 14:30:02 +0000 2009
>Originator:     Jan Danielsson
>Release:        NetBSD/amd64 4.0 RC1
>Organization:
Confuse A Cat Inc.
>Environment:
NetBSD nl102-238-202.student.uu.se 4.0_RC1 NetBSD 4.0_RC1 (ANCABOOT) #0: Wed Sep  5 14:40:43 CEST 2007  jan@nl102-238-202.student.uu.se:/home/jan/netbsd4/rc1/obj.amd64/home/jan/netbsd4/rc1/src/sys/arch/amd64/compile/ANCABOOT amd64

>Description:
When I start postfix, I get this:

--------
nl102-238-202# /etc/rc.d/postfix start                                                                                             
postsuper: fatal: scan_dir_push: open directory defer: Permission denied
postfix/postfix-script: fatal: Postfix integrity check failed!
--------


When I start postgresql, I get this:

--------
nl102-238-202# /etc/rc.d/pgsql start 
Initializing PostgreSQL databases.
The files belonging to this database system will be owned by user "pgsql".
This user must also own the server process.

The database cluster will be initialized with locale C.

creating directory /var/pgsql/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 40
selecting default shared_buffers/max_fsm_pages ... 32MB/204800
creating configuration files ... ok
creating template1 database in /var/pgsql/data/base/1 ... FATAL:  could not open directory "pg_twophase": Permission denied
child process exited with exit code 1
initdb: removing data directory "/var/pgsql/data"
could not open directory "/var/pgsql/data": Permission denied
initdb: failed to remove data directory
--------

In both cases, I have "verified" (with "ls -l") that the permissions are ok.

>How-To-Repeat:

All I need to do on my NetBSD/amd64 4.0 RC1 system is:

# /etc/rc.d/postfix start

# /etc/rc.d/pgsql start


>Fix:
None.

>Audit-Trail:
From: Jan Danielsson <jan.m.danielsson@gmail.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/36963
Date: Mon, 10 Sep 2007 14:57:03 +0200

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA512

    I just remembered a really odd problem I had which is probably
 related. I have a user called pkgsrc which (obviously) is for sync:ing
 pkgsrc, etc. I su:ed to the pkgsrc user, checked out a new fresh copy of
 pkgsrc, and started to browse around the tree. Then I did something else
 for a while. When I switched back to the pkgsrc terminal, and typed "ls
 - -l", I got an error about the directory not being readable. No matter
 what I did, it behaved like someone had pulled the rug from under its
 feet (read: it suddenly lost all it's permissions to its own directory).

    One common denominator between postfix, postgresql and the pkgsrc
 user problem is "su". But I don't know if it's relevant.

 - --
 Kind regards,
 Jan Danielsson

 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.7 (NetBSD)

 iD8DBQFG5T8euPlHKFfKXTYRCsNFAJwIhlNW9LtUDogZ55fgCtYPWSIVHgCfQ/Sl
 ZSqOI/LqvfCgvbk7pCCEgTY=
 =QlOq
 -----END PGP SIGNATURE-----

From: Jan Danielsson <jan.m.danielsson@gmail.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/36963
Date: Mon, 10 Sep 2007 17:31:53 +0200

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA512

    Another thing which may be, or is probably not, relevant. I have
 "init chrooted" (sysctl init.root) from a booted memory disk to a
 harddrive partition. It shouldn't matter, but I'm mentioning it anyway,
 for the record.

 - --
 Kind regards,
 Jan Danielsson

 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.7 (NetBSD)

 iD8DBQFG5WNpuPlHKFfKXTYRCsNbAJ9zoO4tN9wc4RaLSfurcPE3iM4TPACcCxFd
 g+EbVMnmA0bHr79jsDPeWaI=
 =/X0o
 -----END PGP SIGNATURE-----

From: Jan Danielsson <jan.m.danielsson@gmail.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/36963
Date: Sat, 15 Sep 2007 21:30:54 +0200

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA512

    I tried to add a new user, and logged in with it, and ran "ls -l",
 but it immediately complained about a permission problem with ".". But I
 can log in with my normal user without this problem. The only relevant
 difference between between these, afaict is that the new user didn't
 belong to the "wheel" group. I added the new user to the wheel group,
 and tried to log in again, and ran "ls -l". This time it worked.

    So, simply belonging to the group "wheel" seems to make a difference.

    The home directory ownership and group are correct; i.e. owned by the
 user, and the group is "users", and the permissions are rwxr-xr-x.


 - --
 Kind regards,
 Jan Danielsson

 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.7 (NetBSD)

 iD8DBQFG7DLuuPlHKFfKXTYRCiiCAJwIaYUDl6P9QgPJIXs8V8ryDUJ8fACeNuoj
 rXZnxtgEMohKizTyqUsrm7k=
 =YUIT
 -----END PGP SIGNATURE-----

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: jan.m.danielsson@gmail.com
Subject: Re: kern/36963
Date: Sat, 15 Sep 2007 21:44:33 +0200

 On Sat, Sep 15, 2007 at 07:35:03PM +0000, Jan Danielsson wrote:
 >     So, simply belonging to the group "wheel" seems to make a difference.

 Could you ktrace the working and the failing "ls" and check for differences
 in the kdump output?

 Martin

From: Jan Danielsson <jan.m.danielsson@gmail.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/36963
Date: Sun, 16 Sep 2007 18:11:23 +0200

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA512

    The previous comment about how belonging to "wheel" changes things
 may not be relevant. It turns out the permission problem comes and goes.
 It's mostly there, but at times the system seems to behave very
 normally. I must have had some really good timing.

    As Martin Husemann suggested, I tried to kdump the "ls -l", both when
 it was working and when it wasn't. I finally gave up waiting for it to
 work again, so I rebooted. The beginning of the files follows.

    fails.log:
 - --------------------------------------------------------
  24778      1 ktrace   EMUL  "netbsd"
  24778      1 ktrace   CALL
 execve(0x7f7fffffe870,0x7f7fffffed68,0x7f7fffffed80)
  24778      1 ktrace   NAMI  "/home/pkgsrc/bin/ls"
  24778      1 ktrace   RET   execve -1 errno 2 No such file or directory
  24778      1 ktrace   CALL
 execve(0x7f7fffffe870,0x7f7fffffed68,0x7f7fffffed80)
  24778      1 ktrace   NAMI  "/bin/ls"
  24778      1 ktrace   NAMI  "/libexec/ld.elf_so"
  24778      1 ls       EMUL  "netbsd"
  24778      1 ls       RET   execve JUSTRETURN
  24778      1 ls       CALL  mmap(0,0x8000,3,0x1002,0xffffffff,0,0)
  24778      1 ls       RET   mmap 140187698954240/0x7f7ffdff8000
  24778      1 ls       CALL  open(0x7f7ffde0a82e,0,0x7f7ffde0a82e)
  24778      1 ls       NAMI  "/etc/ld.so.conf"
  24778      1 ls       RET   open -1 errno 2 No such file or directory
  24778      1 ls       CALL  open(0x7f7fffffe5d8,0,0xff31302d6e722d62)
  24778      1 ls       NAMI  "/lib/libc.so.12"
  24778      1 ls       RET   open 3
  24778      1 ls       CALL  __fstat30(3,0x7f7fffffe508)
  24778      1 ls       RET   __fstat30 0
  24778      1 ls       CALL  mmap(0,0x1000,1,1,3,0x7f7f00000000,0)
  24778      1 ls       RET   mmap 140187698950144/0x7f7ffdff7000
  24778      1 ls       CALL  munmap(0x7f7ffdff7000,0x1000)
  24778      1 ls       RET   munmap 0
  24778      1 ls       CALL
 mmap(0,0x207000,5,0x14000002,3,0x7f7f00000000,0)
  24778      1 ls       RET   mmap 140187693744128/0x7f7ffdb00000
  24778      1 ls       CALL
 mmap(0x7f7ffdceb000,0xb000,3,0x12,3,0x7f7f00000000,0xeb000)
  24778      1 ls       RET   mmap 140187695755264/0x7f7ffdceb000
  24778      1 ls       CALL
 mmap(0x7f7ffdcf6000,0x11000,3,0x1012,0xffffffff,0x7f7f00000000,0)
  24778      1 ls       RET   mmap 140187695800320/0x7f7ffdcf6000
  24778      1 ls       CALL  mprotect(0x7f7ffdbeb000,0x100000,0)
  24778      1 ls       RET   mprotect 0
  24778      1 ls       CALL  close(3)
  24778      1 ls       RET   close 0
  24778      1 ls       CALL
 __sysctl(0x7f7fffffecb0,2,0x7f7ffdcfa320,0x7f7fffffeca8,0,0)
  24778      1 ls       RET   __sysctl 0
  24778      1 ls       CALL  issetugid
  24778      1 ls       RET   issetugid 0
  24778      1 ls       CALL  ioctl(1,TIOCGETA,0x7f7fffffecc0)
  24778      1 ls       GIO   fd 1 read 44 bytes
        "\^F#\0\0\^C\0\0\0\0\v\0\0\M-O\^E\0
 \^D\M^?\M^?\^?\^W\^U\^R\M^?\^C\^\\^Z\^Y\^Q\^S\^V\^O\^A\0\^T\M^?\0\M^V\0\0\0\M^V\0\0"
  24778      1 ls       RET   ioctl 0
  24778      1 ls       CALL  ioctl(1,TIOCGWINSZ,0x7f7fffffed00)
  24778      1 ls       GIO   fd 1 read 8 bytes
        "@\0\M^D\0\0\0\0\0"
  24778      1 ls       RET   ioctl 0
  24778      1 ls       CALL  getuid
  24778      1 ls       RET   getuid 1001/0x3e9, 1001/0x3e9
  24778      1 ls       CALL
 __sysctl(0x7f7fffffeb80,2,0x7f7fffffeb9c,0x7f7fffffeb90,0,0)
  24778      1 ls       RET   __sysctl 0
  24778      1 ls       CALL  readlink(0x7f7ffdbd92ac,0x7f7fffffebb0,0x3f)
  24778      1 ls       NAMI  "/etc/malloc.conf"
  24778      1 ls       RET   readlink -1 errno 2 No such file or directory
  24778      1 ls       CALL  mmap(0,0x1000,3,0x1002,0xffffffff,0,0)
  24778      1 ls       RET   mmap 140187698950144/0x7f7ffdff7000
  24778      1 ls       CALL  break(0x505838)
  24778      1 ls       RET   break 0
  24778      1 ls       CALL  break(0x506838)
  24778      1 ls       RET   break 0
  24778      1 ls       CALL  break(0x507000)
  24778      1 ls       RET   break 0
  24778      1 ls       CALL  break(0x508000)
  24778      1 ls       RET   break 0
  24778      1 ls       CALL  break(0x509000)
  24778      1 ls       RET   break 0
  24778      1 ls       CALL  break(0x50a000)
  24778      1 ls       RET   break 0
  24778      1 ls       CALL  break(0x50b000)
  24778      1 ls       RET   break 0
  24778      1 ls       CALL  __lstat30(0x50a168,0x50a170)
  24778      1 ls       NAMI  "."
  24778      1 ls       RET   __lstat30 0
  24778      1 ls       CALL  open(0x7f7ffdbd52fc,0,0)
  24778      1 ls       NAMI  "."
  24778      1 ls       RET   open 3
  24778      1 ls       CALL  fcntl(3,2,1)
  24778      1 ls       RET   fcntl 0
  24778      1 ls       CALL  fchdir(3)
  24778      1 ls       RET   fchdir 0
  24778      1 ls       CALL  open(0x7f7ffdbd52fc,0,0)
  24778      1 ls       NAMI  "."
  24778      1 ls       RET   open 4
  24778      1 ls       CALL  open(0x509000,4,0x50a100)
  24778      1 ls       NAMI  "."
  24778      1 ls       RET   open 5
  24778      1 ls       CALL  fcntl(5,2,1)
  24778      1 ls       RET   fcntl 0
  24778      1 ls       CALL  __fstat30(5,0x7f7fffffeb40)
  24778      1 ls       RET   __fstat30 0
  24778      1 ls       CALL
 __sysctl(0x7f7fffffe210,2,0x7f7ffdd05a60,0x7f7fffffe208,0,0)
  24778      1 ls       RET   __sysctl 0
  24778      1 ls       CALL  fstatvfs1(5,0x7f7fffffe270,2)
  24778      1 ls       RET   fstatvfs1 -1 errno 13 Permission denied
  24778      1 ls       CALL  close(5)
  24778      1 ls       RET   close 0
  24778      1 ls       CALL  fchdir(4)
  24778      1 ls       RET   fchdir 0
  24778      1 ls       CALL  close(4)
  24778      1 ls       RET   close 0
 - --------------------------------------------------------


    works.log:
 - --------------------------------------------------------
    959      1 ktrace   EMUL  "netbsd"
    959      1 ktrace   CALL
 execve(0x7f7fffffe870,0x7f7fffffed68,0x7f7fffffed80)
    959      1 ktrace   NAMI  "/home/pkgsrc/bin/ls"
    959      1 ktrace   RET   execve -1 errno 2 No such file or directory
    959      1 ktrace   CALL
 execve(0x7f7fffffe870,0x7f7fffffed68,0x7f7fffffed80)
    959      1 ktrace   NAMI  "/bin/ls"
    959      1 ktrace   NAMI  "/libexec/ld.elf_so"
    959      1 ls       EMUL  "netbsd"
    959      1 ls       RET   execve JUSTRETURN
    959      1 ls       CALL  mmap(0,0x8000,3,0x1002,0xffffffff,0,0)
    959      1 ls       RET   mmap 140187698954240/0x7f7ffdff8000
    959      1 ls       CALL  open(0x7f7ffde0a82e,0,0x7f7ffde0a82e)
    959      1 ls       NAMI  "/etc/ld.so.conf"
    959      1 ls       RET   open -1 errno 2 No such file or directory
    959      1 ls       CALL  open(0x7f7fffffe5d8,0,0xff31302d6e722d62)
    959      1 ls       NAMI  "/lib/libc.so.12"
    959      1 ls       RET   open 3
    959      1 ls       CALL  __fstat30(3,0x7f7fffffe508)
    959      1 ls       RET   __fstat30 0
    959      1 ls       CALL  mmap(0,0x1000,1,1,3,0x7f7f00000000,0)
    959      1 ls       RET   mmap 140187698950144/0x7f7ffdff7000
    959      1 ls       CALL  munmap(0x7f7ffdff7000,0x1000)
    959      1 ls       RET   munmap 0
    959      1 ls       CALL
 mmap(0,0x207000,5,0x14000002,3,0x7f7f00000000,0)
    959      1 ls       RET   mmap 140187693744128/0x7f7ffdb00000
    959      1 ls       CALL
 mmap(0x7f7ffdceb000,0xb000,3,0x12,3,0x7f7f00000000,0xeb000)
    959      1 ls       RET   mmap 140187695755264/0x7f7ffdceb000
    959      1 ls       CALL
 mmap(0x7f7ffdcf6000,0x11000,3,0x1012,0xffffffff,0x7f7f00000000,0)
    959      1 ls       RET   mmap 140187695800320/0x7f7ffdcf6000
    959      1 ls       CALL  mprotect(0x7f7ffdbeb000,0x100000,0)
    959      1 ls       RET   mprotect 0
    959      1 ls       CALL  close(3)
    959      1 ls       RET   close 0
    959      1 ls       CALL
 __sysctl(0x7f7fffffecb0,2,0x7f7ffdcfa320,0x7f7fffffeca8,0,0)
    959      1 ls       RET   __sysctl 0
    959      1 ls       CALL  issetugid
    959      1 ls       RET   issetugid 0
    959      1 ls       CALL  ioctl(1,TIOCGETA,0x7f7fffffecc0)
    959      1 ls       GIO   fd 1 read 44 bytes
        "\^B+\0\0\^C\0\0\0\0K\0\0\M-K\^E\0
 \^D\M^?\M^?\^?\^W\^U\^R\M^?\^C\^\\^Z\^Y\^Q\^S\^V\^O\^A\0\^T\M^?\M^@%\0\0\M^@%\0\0"
    959      1 ls       RET   ioctl 0
    959      1 ls       CALL  ioctl(1,TIOCGWINSZ,0x7f7fffffed00)
    959      1 ls       GIO   fd 1 read 8 bytes
        "2\0P\0\0\0\0\0"
    959      1 ls       RET   ioctl 0
    959      1 ls       CALL  getuid
    959      1 ls       RET   getuid 1001/0x3e9, 1001/0x3e9
    959      1 ls       CALL
 __sysctl(0x7f7fffffeb80,2,0x7f7fffffeb9c,0x7f7fffffeb90,0,0)
    959      1 ls       RET   __sysctl 0
    959      1 ls       CALL  readlink(0x7f7ffdbd92ac,0x7f7fffffebb0,0x3f)
    959      1 ls       NAMI  "/etc/malloc.conf"
    959      1 ls       RET   readlink -1 errno 2 No such file or directory
    959      1 ls       CALL  mmap(0,0x1000,3,0x1002,0xffffffff,0,0)
    959      1 ls       RET   mmap 140187698950144/0x7f7ffdff7000
    959      1 ls       CALL  break(0x505838)
    959      1 ls       RET   break 0
    959      1 ls       CALL  break(0x506838)
    959      1 ls       RET   break 0
    959      1 ls       CALL  break(0x507000)
    959      1 ls       RET   break 0
    959      1 ls       CALL  break(0x508000)
    959      1 ls       RET   break 0
    959      1 ls       CALL  break(0x509000)
    959      1 ls       RET   break 0
    959      1 ls       CALL  break(0x50a000)
    959      1 ls       RET   break 0
    959      1 ls       CALL  break(0x50b000)
    959      1 ls       RET   break 0
    959      1 ls       CALL  __lstat30(0x50a168,0x50a170)
    959      1 ls       NAMI  "."
    959      1 ls       RET   __lstat30 0
    959      1 ls       CALL  open(0x7f7ffdbd52fc,0,0)
    959      1 ls       NAMI  "."
    959      1 ls       RET   open 3
    959      1 ls       CALL  fcntl(3,2,1)
    959      1 ls       RET   fcntl 0
    959      1 ls       CALL  fchdir(3)
    959      1 ls       RET   fchdir 0
    959      1 ls       CALL  open(0x7f7ffdbd52fc,0,0)
    959      1 ls       NAMI  "."
    959      1 ls       RET   open 4
    959      1 ls       CALL  open(0x509000,4,0x50a100)
    959      1 ls       NAMI  "."
    959      1 ls       RET   open 5
    959      1 ls       CALL  fcntl(5,2,1)
    959      1 ls       RET   fcntl 0
    959      1 ls       CALL  __fstat30(5,0x7f7fffffeb40)
    959      1 ls       RET   __fstat30 0
    959      1 ls       CALL
 __sysctl(0x7f7fffffe210,2,0x7f7ffdd05a60,0x7f7fffffe208,0,0)
    959      1 ls       RET   __sysctl 0
    959      1 ls       CALL  fstatvfs1(5,0x7f7fffffe270,2)
    959      1 ls       RET   fstatvfs1 0
    959      1 ls       CALL  break(0x50c000)
    959      1 ls       RET   break 0
    959      1 ls       CALL  __fstat30(5,0x7f7fffffeb50)
    959      1 ls       RET   __fstat30 0
    959      1 ls       CALL  fchdir(5)
    959      1 ls       RET   fchdir 0
    959      1 ls       CALL  lseek(5,0,0,1)
    959      1 ls       RET   lseek 0
    959      1 ls       CALL  __getdents30(5,0x50b000,0x1000)
    959      1 ls       GIO   fd 5 read 440 bytes
 - --------------------------------------------------------

    Lines 40 and 92 (and below) differ.

    When ls fails:
  24778      1 ls       CALL  fstatvfs1(5,0x7f7fffffe270,2)
  24778      1 ls       RET   fstatvfs1 -1 errno 13 Permission denied

    When ls succeeds:
    959      1 ls       CALL  fstatvfs1(5,0x7f7fffffe270,2)
    959      1 ls       RET   fstatvfs1 0

    I find it important to stress that I have done no system
 configuration changes between these runs.


 - --
 Kind regards,
 Jan Danielsson

 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.7 (NetBSD)

 iD8DBQFG7VWruPlHKFfKXTYRCu+lAKCWYHfLAtOoDta01GQlF/9WjsgoVgCghCSb
 JWXrT45cH+YQ9y9Yo4Ed7YQ=
 =/CTo
 -----END PGP SIGNATURE-----

From: Jan Danielsson <jan.m.danielsson@gmail.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/36963
Date: Sun, 16 Sep 2007 23:06:12 +0200

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA512

    I put together the program below. And tried running it in various
 environments.

 - ----------------------------------
 #include <stdio.h>
 #include <dirent.h>

 int main(void)
 {
 	DIR *dirp = opendir(".");
 	if (dirp != NULL)
 	{
 		puts("Success!");
 		(void)closedir(dirp);
 	}
 	else
 	{
 		puts("Error!");
 	}
 	return 0;
 }
 - ----------------------------------

    Using my normal "jan" user (it has never exhibited the permission
 problem):

 $ gcc -o permtest permtest.c
 $ ./permtest
 Success!
 $ cp permtest /tmp/permtest
 $ chmod 755 /tmp/permtest
 $ ls -l /tmp | grep perm
 - -rwxr-xr-x  1 jan   wheel   8431 Sep 16 22:55 permtest

 root:

 # useradd -m test
 # su - test
 $ pwd
 /home/test
 $ /tmp/permtest
 Error!

 .. a few minutes later ..

 # su - test
 $ /tmp/permtest
 Success!

    Note: No changes were made between the runs. It will revert to
 showing "Error!" sooner or later.


 - --
 Kind regards,
 Jan Danielsson

 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.7 (NetBSD)

 iD8DBQFG7ZrEuPlHKFfKXTYRCuTFAJ0bfDyB24T1PvxR2AqlMaiyGs8ewgCfVg/i
 ulS3IVkMSw6AK9kf4jWoqt0=
 =Ptre
 -----END PGP SIGNATURE-----

From: Jan Danielsson <jan.m.danielsson@gmail.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/36963
Date: Mon, 17 Sep 2007 16:24:04 +0200

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA512

    I think I figured out how to make the permissions work again, though
 only temporarily. I simply login with my normal user "jan", and then log
 out again. For some reason, that user always works. And once I have
 performed the login, the other users (pgsql, the www user (for apache),
 pkgsrc, and other test users) can perform the opendir(".") call without
 errors. But after a while, the bug does show up again, and I need to
 login/logout with my "jan" user.

    The only differences between my user "jan" and those which fail are:

    - user id
    - home dir
    - I use bash, the others use nologin, ksh or sh. (But my root user
 also uses ksh, without problems).
    - I belong to the group "wheel", the others don't

 - --
 Kind regards,
 Jan Danielsson

 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.7 (NetBSD)

 iD8DBQFG7o4EuPlHKFfKXTYRCpSeAKCZwR5DwgusoLHOZLvhORf6hWVIogCbBwZ/
 KgZDiLIRsvYUddq7CMZ61UE=
 =cDas
 -----END PGP SIGNATURE-----

From: Jan Danielsson <jan.m.danielsson@gmail.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/36963
Date: Sun, 15 Mar 2009 15:26:02 +0100

     It's strange, but it seems like the problem may be circumvented by 
 booting from a CD rather than from a USB memory key. I have only tried 
 various configurations on three different computers, but it seems that 
 the weird permission problem manifests itself when the system is booted 
 from an USB memory key, while booting from a CD results in a stable OS.

     I haven't seen the problem on i386 (and it doesn't seem like anyone 
 else has, either), so it seems to affect NetBSD/amd64 when booting off USB.

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.