Linda Walsh <law@sgi.com>:
> Jan Harkes wrote:
> >
> > On Mon, Apr 17, 2000 at 05:07:19PM -0700, Linda Walsh wrote:
> > > Jan Harkes wrote:
> > > > static int global_audit_counter = 1;
> > > >
> > > > int sys_newauditid(void)
> > > > {
> > > > lock_kernel();
> > > >
> > > > if (current->auditid && !capable(CAP_NEW_AUDIT_ID))
> > > > return -EPERM;
> > > >
> > > > current->auditid = global_audit_counter++;
> > > >
> > > > unlock_kernel();
> > > >
> > > > return 0;
> > > > }
> > > ---
> > > How about to the first -- define UID=-1 as an invalid UID.
> > > Then in set_luid, if you pass it -1, it returns the audit_counter and
> > > sets luid to that value, else for all other integers set_luid to that value.
> > > Then we both get exactly the behaviors we want.
> >
> > That wouldn't be very useful, I think we both need very well defined
> > semantics, otherwise someone installing Coda on a system with auditing
> > would unintentionally mess up both Coda's user-session mapping and the
> > auditing process at the same time.
> ---
> Hrumph. Ok...how about an LUID *and* a SessUID. We can use the
> same system calls for both -- SessUID would be returned and set if
> the system call was called with "-1". The get code would return LUID if
> 0 passed in, SessUID if 1 passed in. Then at the libc level, you have
> simple calls to call the underlying kernel call -- heck just make them
> #defines....
>
> get_session_id()
> -> audit_id(1)
> get_luid()
> -> audit_id(0)
>
> gen_session_id()
> -> cntrol_audit_id(-1)
>
> set_luid(arg)
> -> cntrol_audit_id(arg)
>
> The CAP becomes the POSIX CAP "CAP_AUDIT_CONTROL" that allows you
> control generation or setting.
>
> Now question -- is a 32-bit number big enough for session id's? On one
> of our systems here, it's only been up for 12 days and it's up to
> process 4.8 million. I suppose you should have alot fewer sessions than
> processes so I guess it'd be enough.
Ummm... I'd suggest a 64 bit value - consider what a session might be
in a cluster. 128 systems, each running 700 - 1000MHz, communicating
with MPI.... It would be nice to be able to audit the entire cluster as
a single unit, rather than 128 separate systems. A 256 node cluster would
start to get very painfull to trace a single job. I do expect that the
hostid would be recorded along with audit events, so that can be used to
identify the node in a cluster.
> I'll mumble the code again if this works for you.
>
> One of the glibc people here pointed out that I shouldn't return the UID
> from the set function as a 32 bit UID value could correspond to one of the
> ERROR values (EPERM in this case) I'd want to return.
You'll have to consider adding an address for the return value, and using the
function return for the status.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:15 EST