OK, so I think I have/took the action item to implement this but was talking w/a
co-worker. Is 32-bits enough for a session counter? If we want the algorithm
to be simple -- not having to check through all processes to see if a session
id is already in use, it seems a 32-bit value could wrap on a system that's
been up for something in the range of 'years'. Yeah, so ok, it's a long term
problem, but something we should probably design right the first time. So...
anyone have a problem with a 64-bit value -- that should be fairly unique in our
lifetimes. :-)
An alternative is to issue a warning on all terms/syslog that it has wrapped and
they should reboot their machine, but that's rather inelegant...
Another problem is 'cron'. While 'at' can encode an luid in the job name how
do you tell what authorized user is running a 'cronjob'? One authorized
user could be executing an SUID program to another user and edit that user's
crontab. The only way I can come up with there is to dis-allow user-level
cronjobs on a secure system (using existing configuration options:
cron.allow/deny).
Any comments?
-linda
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:19 EST