Jesse Pollard wrote:
>
> That shouldn't happen with session IDs; they should not be associated with a
> tty. If it does, then we do need something that is unique to each
> login/session that accomplishes that.
-- Actually the creation of a session seems to happen when you disassociate from a tty. Here's the code for set:asmlinkage int sys_setsid(void) { struct task_struct * p; int err = -EPERM; read_lock(&tasklist_lock); for_each_task(p) { if (p->pgrp == current->pid) goto out; } current->leader = 1; current->session = current->pgrp = current->pid; current->tty = NULL; current->tty_old_pgrp = 0; err = current->pgrp; out: read_unlock(&tasklist_lock); return err; } --- It sets up a new process group as well -- both become equal to the pid of the calling process. There seem to be no restrictions on when it is called. This is not suitable for requirements of the CAPP or LSPP.
> > Sessionid has existing semantics. I assert that we shouldn't change > >the existing semantics w/o breaking existing code that relies on its current > >behavior (e.g. X). > > I never noticed that X used different sessions - Linux would be the first > one I've seen that did.at --- Whether 'X' uses it or not I really don't know. But the point is the current semantics aren't what you or I want. CAPP requires auditing by Login-user ID, not by session #. If you log by session #, you would have to go through an exhaustive proof that *all* sessions can be tracked back to a an authorized login (cron or at). Interestingly enough, for 'at' IRIX encodes the LUID in the name of the 'at' job. If cron doesn't have a similar mechanism, to meet requirements, one might disable user-level cron jobs.
> > If it is necessary to have yet another thing - I would recommend a true session > identifier rather than a LUID. The session ID eliminates having to follow > chains of things like fork/exec/ipc calls/rpc calls ... --- It is not an either/or thing. Feel free to propose your session ID and throw in the code. I don't care one way or the other. I can see a use for it. I wouldn't be against it. But it's not what I am wanting. I would add that having such a session_id would be a useful addition to auditing, but it isn't required to meet the CA or LS Protection Profiles.
> Something unique like the current time concatenated with a counter since last > boot would work. At the present time, I wouldn't want the identifier to > repeat within the last 3-5 years (effectively, we are not allowed to delete any > audit logs until the system generating has been removed for at least 1 year). --- Maybe we should use a "GUID" -- Globally Unique ID. :-) (*danger will robinson*) > The full audit trail tracing an event becomes available with a simple select > of a given session ID followed by a sort by time. The result presents all > activity from the instant the session started. --- It would be very useful in report generation, but given the right post-processing tools to create the back (fork) chains sorted by LUID and login time one can also create the same report.
-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:10 EST