Date: Fri, 2 Nov 2001 15:04:58 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org> Cc: Kelly Yancey <kbyanc@posi.net>, arch@FreeBSD.org, Julian Elischer <julian@elischer.org>, Garance A Drosihn <drosih@rpi.edu> Subject: Re: Changes to suser() and friends Message-ID: <Pine.NEB.3.96L.1011102144159.21159J-100000@fledge.watson.org> In-Reply-To: <XFMail.011102112429.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1011102144159.21159J-100000>