From owner-freebsd-arch Fri Nov 2 12: 5:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 66E7F37B40A; Fri, 2 Nov 2001 12:05:05 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fA2K4wB27781; Fri, 2 Nov 2001 15:04:58 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Fri, 2 Nov 2001 15:04:58 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: John Baldwin Cc: Kelly Yancey , arch@FreeBSD.org, Julian Elischer , Garance A Drosihn Subject: Re: Changes to suser() and friends In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 2 Nov 2001, John Baldwin wrote: > Agreed. After chatting a bit with rwatson on IRC, my conclusion is for > the following two functions. I'm not sure worrying over includes is all > that valuable, but having drivers and filesystems be able to handle > threads and procs in the abstract instead of having to muck with their > innards is cleaner. These two functions remove any ambiguity about what > ucred is being used as well. This ambiguity was one of my primary concerns with the current interface. > int suser(struct thread *td, int flags) > Uses td->td_proc->td_ucred for its ucred. Fairly soon it will switch > to td->td_ucred when that is safe to do so. Note that this will only > be useful for curthread. > int suser_cred(struct ucred *cred, int flags) > Uses cred for its ucred. Useful in places where you want to use a ucred > other than a thread's ucred. Such as the process ucred, cached struct file ucred, cached struct socket ucred, VFS-provided ucred, ... > suser() really is all about ucreds, so I can appreciate Robert's desire > to have one function that just takes a ucred, but I like preserving the > existing abstraction of d_thread_t. It will also make keeping code > portable between 4.x and 5.x easier. I'm fine with these, and accept the binary compatibility argument: that is, in general it would be nice if drivers did not have to grope around in these structures, improving the data hiding aspect. I suspect, however, an important strategy will be to remove some of the extraneous use of suser() in drivers, which most of the time are able to rely on the file system/device node protections. Given that a move towards fine-grained access control will require added includes in these drivers anyway, so I think on face value the #include concern is somewhat bogus; a strategy of avoiding unnecessary access control in the drivers would address this problem also, however. I'll write up a patch with these changes, and post it for review RSN. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message