Date: Thu, 23 Oct 1997 17:24:41 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: thorpej@nas.nasa.gov Cc: jamil@trojanhorse.ml.org, joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG Subject: Re: Possible SERIOUS bug in open()? Message-ID: <199710231724.KAA25749@usr02.primenet.com> In-Reply-To: <199710220909.CAA13732@lestat.nas.nasa.gov> from "Jason Thorpe" at Oct 22, 97 02:09:44 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > How exactly did you fix it, this is related to what I was saying about > > opening a file as RD_ONLY and WR_ONLY, because if oflags = -1 then fflags > > = 0 and that means the file is not open for read or write which my point > > was that it should be forced to be open for one or the other. I don't > > rememer who, but someone seemed to think that it could be actually useful > > to hav a file not open for read or write > > How would opening for !read !write be useful? What else could you possibly > want to do? (Yes, this is a trick question :-) Hold a reference instance, but don't let your children have access to read or write the device (ie: things like /dev/io). Hold a reference instance to keep a Streams or similar stack instantiated, even though you personally don't use it, because whoever does has a tendency to crash and would otherwise take the stack with them and make it necessary to rebuild the thing. Call fcntl( fd, F_GETOWN, ...) Call fdopen(), allowing the fd to be there, but not accessable except through stdio updating the mode value Proxy locks for NFS server locking, and use the lack of FREAD|FWRITE to signal close(2) to override POSIX close/lock interaction semantics. Call poll(2) on a directory to see if anything was added to it or removed from it. Become the process group leader on a tty so you get the SIGHUP on ON-to-OFF DCD transition, but not do I/O (for example a session manager on a tty, used as a credential holder for non-UNIX credentials, for things like an SMB or NetWare client FS). For use on a directory by a user usable "mount" command, without giving full corresponding access to the user. There are a *lot* of reasons. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710231724.KAA25749>