Jan Harkes wrote:
>
> On Mon, Apr 17, 2000 at 03:53:47PM -0700, Linda Walsh wrote:
> > Jan Harkes wrote:
> > > How is this less secure than the luid?
> > > How is this [not] usable as an equivalent to the luid?
> > ---
> > It provides less flexibility in the user space to implement
> > policy. For example. I've been mulling over how to solve the daemon vs.
> > root conundrum. It seems that first thing init might do is set_luid(daemon).
>
> Let's bring back the capabilities stuff. I actually believe we might be
> getting somewhere.
>
> 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;
> }
>
> int sys_getauditid(void)
> {
> return current->auditid;
>
--- 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. I'm just not wanting to write post-processing to have to map all the session numbers to the UID to fulfill the need for per-authenticated user accountability.-l
-- Linda A Walsh | Trust Technology, Core Linux, SGI law@sgi.com | Voice: (650) 933-5338
- 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:12 EST