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>