Date: Thu, 3 Apr 1997 17:47:04 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dg@root.com Cc: terry@lambert.org, current@FreeBSD.ORG Subject: Re: DISCUSS: system open file table Message-ID: <199704040047.RAA17931@phaeton.artisoft.com> In-Reply-To: <199704040036.QAA05861@root.com> from "David Greenman" at Apr 3, 97 04:36:50 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >4) Any other kernel file I/O operations which rely > > on stored credentials established at file open(*). > > > > (*) The descriptor f_type and f_ops field are not > > relevent arguments in favor of this, since they > > are cruft which should be diked out. > > It's already trivially easy to do file I/O in the kernel without a file > descriptor. As you know, a "file descriptor" in FreeBSD is only a mechanism > to translate a per-process file handle to a kernel vnode. For this reason, > the very notion of a "file descriptor" is only relevant in the context of > a process. It sounds like #4 is the main thing you're after, but I fail to > see how this is relevant unless you have a process context in which to do > the I/O, and in that case you already have easy access to the process' > credentials. But... currently, a vnode reference is not the same thing as an open reference. Also, for things like a CIFS/SMBFS/AppleTalk/NetWare client, I want to be able to use credentials which are not BSD process credentials, but user credentials. If a vnode reference becomes an open reference, this resolves a lot of things, but it still doesn't resolve traversal of the system open file table, which is needed by sysctl (in general), identd (for credential vouchsafing), and for accounting reasons (when I want to unmount an FS with open files, etc.). I want to make the distinction between a cached reference and a real reference, as well, both for the file I/O in a kernel thread, and to get around some of the recent problems that come from VOP_LOCK handling two types of locks. Finally, there is the issue of taking faults in kernel mode without a process context to sleep on. I'd like to see the sleeping moved to the address of the field in the system open file table,so that the sleep handle doesn't have to know what kind of caller is making the call. Regards, 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?199704040047.RAA17931>