Re: bin/60493: autofs does not handle chroot

["Simon J. Gerraty via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR bin/60493; it has been noted by GNATS.

From: "Simon J. Gerraty" <sjg%crufty.net@localhost>
To: Taylor R Campbell <riastradh%NetBSD.org@localhost>
Cc: netbsd-bugs%netbsd.org@localhost, gnats-bugs%netbsd.org@localhost, sjg%crufty.net@localhost
Subject: Re: bin/60493: autofs does not handle chroot
Date: Wed, 19 Aug 2026 16:05:00 -0700

 TL;DR; the latest patch in the PR worked.
 
 >The kernel will print the full path (ar_path in autofs_trigger_one).
 >What's interesting is what path it passed to automountd (adr_path in
 >autofs_ioctl_request) and whether automountd did anything.
 >
 >Sounds like it's time for some printf debugging!
 >
 >You could also just try ktracing automountd to see if the ioctl
 >response looks sensible.
 
 Ok, I unpacked base and etc sets in chroot and
 created auto_master that only defines one map /pics (~/bin/autofs just
 runs all the rc.d/auto* in correct order)
 
 # ~/bin/autofs off
 # chroot $ROOT /bin/ksh
 # ~/bin/autofs on
 # ls /pics/2026
 
 that at least did not hang.
 
 # mount
 map /etc/autofs/pics on /pics type autofs
 /dev/dk6 on / type ffs (local)
 #
 
 I note that auto* created /pics ok
 
 # ktrace -i -f /var/tmp/kt -p `cat /var/run/automountd.pid`
 # ls /pics/2026
 # ls /pics/2025
 # ktrace -C
 # kdump -E -f /var/tmp/kt > /var/tmp/kd
 
 /var/tmp/kd shows
 
 ..
  17093  17093 mount_nfs 0.002363788 CALL  __lstat50(0x7f7fffe02470,0x7f7ff=
 =3D
 fe01620)
  17093  17093 mount_nfs 0.002365394 NAMI  "/pics"
  17093  17093 mount_nfs 0.002369445 RET   __lstat50 0
  17093  17093 mount_nfs 0.002370911 CALL  __lstat50(0x7f7fffe02470,0x7f7ff=
 =3D
 fe01620)
  17093  17093 mount_nfs 0.002372098 NAMI  "/pics/2026"
 
 that's promising
 
 ..
  17093  17093 mount_nfs 0.031513795 CALL  connect(5,0x7734ec9d2080,0x10)
  17093  17093 mount_nfs 0.031514633 MISC  mbsoname: [192.168.66.6]
  17093  17093 mount_nfs 0.032295206 RET   connect 0
 
 that's the server
 
 ..
  17093  17093 mount_nfs 0.032299746 CALL  getsockname(5,0x7f7fffe01ab0,0x7=
 =3D
 f7fffe
 01aa8)
  17093  17093 mount_nfs 0.032301073 MISC  mbsoname: [192.168.66.11]
  17093  17093 mount_nfs 0.032302050 RET   getsockname 0
 
 that's the client
 
 ..
  17093  17093 mount_nfs 0.032401359 CALL  write(5,0x7734ec904b80,0x80)
  17093  17093 mount_nfs 0.032409041 GIO   fd 5 wrote 128 bytes
        "\M^@\0\0|\M-R\^[@N\0\0\0\0\0\0\0\^B\0\^A\M^F\M-%\0\0\0\^C\0\0\0\^A=
 =3D
 \0\0\
         \0\^A\0\0\0Djz\^T\M-`\0\0\0\^Nbad.crufty.net\0\0\0\0\0\0\0\0\0\0\0=
 =3D
 \0\0\
         \b\0\0\0\0\0\0\0\^B\0\0\0\^C\0\0\0\^D\0\0\0\^E\0\0\0\^T\0\0\0\^_\0=
 =3D
 \0\0\
         \"\0\0\0\0\0\0\0\0\0\0\0\n/pics/2026\0\0"
  17093  17093 mount_nfs 0.032410019 RET   write 128/0x80
 
 that looks like a sane request?
 
 ..
   17093  17093 mount_nfs 0.033066840 CALL  read(5,0x7734ec8f3c00,0x10000)
   17093  17093 mount_nfs 0.033083322 GIO   fd 5 read 32 bytes
         "\M^@\0\0\^\\M-R\^[@N\0\0\0\^A\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
 =3D
 \0\r"
   17093  17093 mount_nfs 0.033084160 RET   read 32/0x20
 
 I presume that's the response
 
 ..
  17093  17093 mount_nfs 0.033127529 CALL  write(2,0x7f7fffe01780,0xb)
  17093  17093 mount_nfs 0.033131929 GIO   fd 2 wrote 11 bytes
        "mount_nfs: "
  17093  17093 mount_nfs 0.033132906 RET   write 11/0xb
  17093  17093 mount_nfs 0.033134932 CALL  write(2,0x7f7fffe01860,0x2a)
  17093  17093 mount_nfs 0.033136468 GIO   fd 2 wrote 42 bytes
        "can't access /pics/2026: Permission denied"
 
 ..
  17093  17093 mount_nfs 0.033198553 CALL  exit(1)
  17702  17702 automountd 0.033440959 RET   __wait450 -1 errno 4 Interrupte=
 =3D
 d system call
  17702  17702 automountd 0.033444451 PSIG  SIGCHLD caught handler=3D3D0xab=
 f7=3D
 0 mask=3D3D(): code=3D3DCLD_EXITED child pid=3D3D17093, uid=3D3D0, status=3D=
 3D1, uti=3D
 me=3D3D0, stime=3D3D0)
 
 Everything about that seemed sane - apart from the result ;-)
 
 Check the server and we see
 
 Aug 10 11:26:02 beast mountd[74725]: mount request denied from 192.168.66.=
 11 for /pics/2026
 
 Ok, export of /pics is missing --alldirs (as we have on /homes)
 
 Mounting just /pics works fine within chroot:
 
 # ~/bin/autofs off
 mount beast:/pics /pics
 # ls /pics/2026
 01              03              07              index.htm       meta.prope=
 =3D
 rties
 02              05              08              index.htm.old
 # umount /pics
 
 Add -alldirs and try again
 
 # ~/bin/autofs on
 # ls /pics/2026
 01              03              07              index.htm       meta.prope=
 =3D
 rties
 02              05              08              index.htm.old
 #
 
 success!
 
 Thanks
 --sjg