Subject: very strange problem with vi temporary files on "somewhat -current" diskless client
To: NetBSD-current Discussion List <current-users@NetBSD.ORG>
From: Greg A. Woods <woods@weird.com>
List: current-users
Date: 01/22/2002 00:30:37
I've encountered a rather bizzare behaviour with unlink(2) on a diskless
sparcstation running -current from 2001/06/24, served by another sparc
running the same software.  Vi complains that it cannot remove its
temporary files, but they can be removed, by their owner, after vi exits.
This happens both for "root" and an ordinary user-id, but only on the
client with NFS-mounted /tmp and /var -- no problems on the server.  The
mounts are done with the following entries in /etc/exports on the server:

	/ -maproot=root -alldirs -network 204.92.254.0 -mask 255.255.255.0
	/swap -maproot=root -alldirs -network 204.92.254.0 -mask 255.255.255.0
	/var -maproot=root -alldirs -network 204.92.254.0 -mask 255.255.255.0

And these /etc/fstab entries on the client:

sometimes.weird.com:/very       /       nfs     rw              0       0
sometimes.weird.com:/swap       /swap   nfs     rw              0       0
/swap/very                      none    swap    sw
sometimes.weird.com:/usr        /usr    nfs     rw              0       0
sometimes.weird.com:/var/very   /var    nfs     rw              0       0
proven.weird.com:/home          /home   nfs     rw,nosuid       0       0

  BTW, why can't I mount a plain file directly for swap like I did with
  1.3.x, using the likes of:
	most.weird.com:/var/swap/very   none    swap    sw,nfsmntpt=/swap
  -- now I seem to need to mount a whole sub-directory with the swap
  file in it....  (netbsd seems to ignore booparams swap & dump settings
  too, but yet requires a gateway setting contrary to one manual page,
  bootparams(5), but not another, diskless(8)....)

Here's what kdump has to say about the unlink() errors and the files
they fail on:

  4595 vi       CALL  getpid
  4595 vi       RET   getpid 4595/0x11f3
  4595 vi       CALL  __stat13(0xefffdbe0,0xefffdaa0)
  4595 vi       NAMI  "/tmp/"
  4595 vi       RET   __stat13 0
  4595 vi       CALL  open(0xefffdbe0,0xa02,0x180)
  4595 vi       NAMI  "/tmp//bt.04595a"
  4595 vi       RET   open 4
  4595 vi       CALL  unlink(0xefffdbe0)
  4595 vi       NAMI  "/tmp//bt.04595a"
  4595 vi       RET   unlink -1 errno 13 Permission denied
[[....]]
  4595 vi       CALL  getpid
  4595 vi       RET   getpid 4595/0x11f3
  4595 vi       CALL  __stat13(0xefffe080,0xefffdf40)
  4595 vi       NAMI  "/tmp/"
  4595 vi       RET   __stat13 0
  4595 vi       CALL  open(0xefffe080,0xa02,0x180)
  4595 vi       NAMI  "/tmp//bt.04595d"
  4595 vi       RET   open 5
  4595 vi       CALL  unlink(0xefffe080)
  4595 vi       NAMI  "/tmp//bt.04595d"
  4595 vi       RET   unlink -1 errno 13 Permission denied
[[....]]
  4595 vi       CALL  unlink(0xd01f0)
  4595 vi       NAMI  "/tmp/vi.04595b"
  4595 vi       RET   unlink -1 errno 13 Permission denied
[[....]]
  4595 vi       CALL  write(0x1,0x11f000,0x38)
  4595 vi       GIO   fd 1 wrote 56 bytes
       "\^[[7mError: /tmp/vi.04595b: remove: Permission denied\r\^[[m"
  4595 vi       RET   write 56/0x38
  4595 vi       CALL  close(0x3)
  4595 vi       RET   close 0
  4595 vi       CALL  close(0x4)
  4595 vi       RET   close 0
  4595 vi       CALL  close(0x5)
  4595 vi       RET   close 0
  4595 vi       CALL  unlink(0xcd1e0)
  4595 vi       NAMI  "/var/tmp/vi.recover/vi.04595c"
  4595 vi       RET   unlink 0
  4595 vi       CALL  unlink(0xe46c0)
  4595 vi       NAMI  "/var/tmp/vi.recover/recover.04595e"
  4595 vi       RET   unlink -1 errno 13 Permission denied
[[....]]
  4595 vi       CALL  write(0x1,0x11f000,0x93)
  4595 vi       GIO   fd 1 wrote 147 bytes
       "\^[[A\^[[A\^[[7m+=+=+=+=+=+=+=+\r
        Error: /tmp/vi.04595b: remove: Permission denied.\^[[42;9Hvar/tmp/vi.r\
        ecover/recover.04595e: remove: Permission denied\r\^[[m"
  4595 vi       RET   write 147/0x93


I was going to speculate that the problem might be related to unlinking
a locked file over NFS, but for at least the first file there's no
fcntl() or flock() until after the unlink() is done, and of course
there's this bug mentioned in rpc.lockd(8):

	there is currently no means for a NetBSD client to establish locks



Should I send-pr this unlink() problem?


Also curious is that I get an EIO instead of EPERM when I try to remove
a file I don't own in a mode 01777 directory:

	$ ls -la /var/tmp/vi.recover
	total 22
	drwxrwxrwt  2 root   wheel  512 Jan 21 23:59 .
	drwxrwxrwt  3 root   wheel  512 Jan 21 20:07 ..
	-rw-------  1 root   wheel  436 Jan 20 20:18 recover.02682d
	-rw-------  1 root   wheel  436 Jan 20 20:20 recover.02694d
	-rw-------  1 root   wheel  436 Jan 20 20:20 recover.02702d
	-rw-------  1 root   wheel  436 Jan 20 20:21 recover.02720d
	-rw-------  1 root   wheel  428 Jan 21 17:59 recover.04428d
	-rw-------  1 woods  wheel  407 Jan 21 19:55 recover.04575e
	-rw-------  1 woods  wheel  434 Jan 21 20:05 recover.04595e
	-rw-------  1 root   wheel  448 Jan 21 23:35 recover.04782d
	-rw-------  1 root   wheel  452 Jan 21 23:37 recover.04783d
	-rw-------  1 woods  wheel  442 Jan 21 23:58 recover.04806e
	-rwx------  1 root   wheel    0 Jan 20 20:20 vi.02703b
	$ rm /var/tmp/vi.recover/*
	rm: /var/tmp/vi.recover/recover.02682d: Input/output error
	rm: /var/tmp/vi.recover/recover.02694d: Input/output error
	rm: /var/tmp/vi.recover/recover.02702d: Input/output error
	rm: /var/tmp/vi.recover/recover.02720d: Input/output error
	rm: /var/tmp/vi.recover/recover.04428d: Input/output error
	rm: /var/tmp/vi.recover/recover.04782d: Input/output error
	rm: /var/tmp/vi.recover/recover.04783d: Input/output error
	rm: /var/tmp/vi.recover/vi.02703b: Input/output error

On a regular ffs the same error is the expected EPERM:

	$ rm -f /var/tmp/myfile
	rm: /var/tmp/a-root-file: Operation not permitted

Should I send-pr this too?


BTW, why does vi, or some library routine it calls, do these
ioctl(TIOCGETA)'s on a "normal" file!?!?!?:

  4595 vi       CALL  getuid
  4595 vi       RET   getuid 1000/0x3e8
  4595 vi       CALL  __stat13(0xafa90,0xefffd188)
  4595 vi       NAMI  "/etc/nsswitch.conf"
  4595 vi       RET   __stat13 0
  4595 vi       CALL  open(0xafa90,0,0x1b6)
  4595 vi       NAMI  "/etc/nsswitch.conf"
  4595 vi       RET   open 6
  4595 vi       CALL  ioctl(0x6,TIOCGETA,0xefffcf40)
  4595 vi       RET   ioctl -1 errno 25 Inappropriate ioctl for device
  4595 vi       CALL  __fstat13(0x6,0xefffce30)
  4595 vi       RET   __fstat13 0
  4595 vi       CALL  read(0x6,0xd3000,0x2000)
  4595 vi       GIO   fd 6 read 602 bytes
       "#       $NetBSD: nsswitch.conf,v 1.5 1999/10/24 12:36:52 lukem Exp $
  4595 vi       RET   read 602/0x25a
  4595 vi       CALL  read(0x6,0xd3000,0x2000)
  4595 vi       RET   read 0
  4595 vi       CALL  ioctl(0x6,TIOCGETA,0xefffced8)
  4595 vi       RET   ioctl -1 errno 25 Inappropriate ioctl for device
  4595 vi       CALL  close(0x6)
  4595 vi       RET   close 0

(no, I haven't, yet, looked at the source w.r.t. this....  :-)

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>