Re: bin/60493: autofs does not handle chroot

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=
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=
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=
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=
\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=
\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=
\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=
\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=
d system call
 17702  17702 automountd 0.033444451 PSIG  SIGCHLD caught handler=3D0xabf7=
0 mask=3D(): code=3DCLD_EXITED child pid=3D17093, uid=3D0, status=3D1, uti=
me=3D0, stime=3D0)

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=
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=
rties
02              05              08              index.htm.old
#

success!

Thanks
--sjg