On Jan 2, 2007, at 10:21 AM, Jim Rees wrote:
Nothing in the kernel module (is that what you meant?) should be
calling
suser(). Calls should be to afs_osi_suser(), which is in afs_osi.c
and
calls afs_suser(), which is implemented in the systype-dependent
source.
I haven't seen your patch, but it should call priv_policy from just
one
place. It could be a macro defined in SOLARIS/osi_machdep.h or a
function.
The calls to suser() in SOLARIS/osi_vfsops.c should be changed to
afs_suser.
In my opinion we don't need both afs_osi_suser and afs_suser.
These are my sentiments, and I spent a good amount of time trying to
make sense of afs_osi_suser and afs_suser. Here's what I found, and
what my two patches do:
1) afs_osi_suser(), as defined in src/afs/afs_osi.c, originally (and
still is for most platforms) just a wrappere to afs_suser(), which is
defined only under UKERNEL. This in itself perplexed me.
2) In src/afs/SOLARIS/osi_machdep.h, there was a macro defined:
afs_suser(x) -> suser(x).
3) afs_mount() and afs_unmount() in src/afs/SOLARIS/osi_vfsops.c
called suser() directly.
My two patches do the following:
1) Adds a #ifdef for Solaris 10 to afs_osi_suser() to call priv_policy
() instead of afs_suser(). The original behavior is kept for Solaris
< 10.
2) Adds a macro for Solaris 10 to map afs_suser(x) to afs_osi_suser
(x). The original behavior is kept for Solaris < 10. The afs_suser()
macro is still needed as afs_suser() is still called, mainly by stuff
in src/afs/osi_pioctl.c. I guess these should also be changed to
afs_osi_suser ?
3) Any code in the solaris driver which called afs_suser() now calls
afs_osi_suser (osi_inode.c was the main offender here). For all
Solaris revs. (for Solaris < 10, this is ultimately a call to suser() )
4) The straight suser() calls in afs_mount() and afs_unmount() were
changed to call secpolicy_fs_mount() and secpolicy_fs_unmount()
respectively for Solaris 10. For Solaris < 10, it is now a call to
afs_osi_suser()
/dale
--
Dale Ghent
UNIX Systems Specialist
UMBC - Office of Information Technology
ECS 201 - x51705
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
