Date: Sat, 3 Jun 2000 16:42:04 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: Chris Costello <chris@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/miscfs/fdesc fdesc.h fdesc_vnops.c Message-ID: <Pine.BSF.4.21.0006031612460.2058-100000@besplex.bde.org> In-Reply-To: <200006021534.LAA41585@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2 Jun 2000, Garrett Wollman wrote: > <<On Fri, 2 Jun 2000 00:02:46 -0700 (PDT), Chris Costello <chris@FreeBSD.org> said: > > > - Do not allow VOP_SETATTR to modify underlying vnodes at all. This caused > > problems when fetch(1) was passed `-o -'. The rationale of this change > > is that applications attempting to change underlying vnodes for /dev/fd > > nodes are improperly written and the use of this interface should not > > ever have been encouraged. Proper alternatives are fchmod, fchown and > > others. I think accesses by name should change the underlying vnode if there is one. The aliasing is similar to the one given by hard links. If someone hard links /dev/null to /tmp/foo and then does a chmod on /tmp/foo, the chmod will affect the vnode for /dev/null, although that is unlikely to be what was intended (and it will fail unless the someone is root). The bug in fdesc apparently involves pipes. Things seem to have been broken in rev.1.35 of fdesc_vnops.c. Nameless pipes (DTYPE_PIPE) don't have vnodes, so they shouldn't be handled like named pipes (DTYPE_FIFO). > Huh? The only operations `fetch' *ever* performs on /dev/stdout are: > > fopen > fseek > fwrite > fread (iff the server provides an MD5) (which will fail anyway) It is missing the `to_stdout' test in several places, so it attempts to do some operations on "-". According to ktrace, the only bad NAMI for a simple http fetch was one for utimes(). This error is silently ignored, of course. > I'd make the additional argument that this change is bogus because: > > If fetch had been passed `-o /dev/fd/69', it would be unreasonable to > expect fetch to examine the argument it was given, notice that it > began with the magic string `/dev/fd/' and parse out the > file-descriptor number. I think parsing "-" is bogus too :-). > This is not to say that there are no bugs in `fetch' -- I found a > couple in the vicinity of rm() just by inspection, one of which > actually bit me once. (Hint: never interrupt fetch while running as > root with `-o /dev/null' -- it will delete the device node.) This seems to be a popular bug. "gcc-2.4.5 -o /dev/null ..." attempted to unlink /dev/null after any error. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0006031612460.2058-100000>