Re: syscall convention

jmjonesat_private

On Tue, 21 Aug 2001, Chris Wright wrote:

> * richard offer (offerat_private) wrote:
> > 
> > 
> > * frm offerat_private "08/21/01 15:27:23 -0700" | sed '1,$s/^/* /'
> > *
> > * 
> >  
> > * I will submit a patch that adds an extra parameter to syscall 
> > * 
> > *     sys_security(int modid, int cmd, unsigned long *args) 
> > * 
> > * for the private use of the module.
> > 
> > 
> > Attached is the proposal (against ChangeSetat_private, 2001-08-21
> > 11:34:20-04:00 by Stephen)
> > 
> > The prototype is now
> > 
> >     int sys_security(unsigned int modid, unsigned int call, unsigned long
> > *args);
> 
> you forgot to actually change the implementation of the sys_security
> syscall. (note: there is still signed/unsigned mismatch).
> 
> -chris
> 

I noticed this, also.  The hooks were changed (admirably) but the catcher
for the hook was not.

BUT (big butt)... what's to dislike?  Do this patch, do the other patch
(the one that changes sys_security_syscall()) in sys.c... 

Eliminate the modid check, eliminate the copy_to from user to kernel, and
back... what does that leave

sys_security_syscall(unsigned int modid,in call, unsigned long *arg)
{
  return security_ops->syscall(modid,call,arg);
}

Anything else that I missed?

It MIGHT seem, to me, that security.c might patch this hook right into the
proper place, lifting a pointer from the security_ops structure... so
modules don't have to place it explicitly.  

Either "register_security_syscall()" or just an implied "lift" from 
"register_security()"... since it's something that will be done no matter
what?

It Looks Great To Me,
J. Melvin Jones

|>------------------------------------------------------
||  J. MELVIN JONES            jmjonesat_private 
|>------------------------------------------------------
||  Microcomputer Systems Consultant  
||  Software Developer
||  Web Site Design, Hosting, and Administration
||  Network and Systems Administration
|>------------------------------------------------------
||  http://www.jmjones.com/
|>------------------------------------------------------

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module