>from /proc/*/psinfo: >* pr_psargs (first 80 characters of args as of exec time) >* pr_fname (exec name) >* pr_argv (offsets into process address space?)
Correct; and you need to have access to the process memory before you can dereference them. (ps is no longer set-uid root; even ps, then, has to follow that rule) >Directly from kmem (in an instance of struct proc): >* p_user.u_psargs (same as pr_psargs) >* p_user.u_argv (similar to pr_argv) >* p_user.u_comm (haven't checked if that corresponds to pr_fname) Note that the "/proc/*/psinfo" structures are created when they are accessed; we're always reading them from p_user. >ISTR that sendmail has a function called setproctitle() or somesuch; that >will re-create the commands args, which /usr/ucb/ps auxw will see _if_ >one is the same euid as the process (or root), so that one has permission >to read the address space; otherwise one only sees the saved 80 characters >as of the latest exec in that process, which is also what /usr/bin/ps -f >shows. If we want to make an interface, then setproctitle is the interface we should emulate. >There is no facility for resetting u_psargs or pr_psargs, as far as I know. >Notwithstanding that it might be pretty and/or informative to do so, >it might also be used for evil purposes, i.e. some nasty program trying >to pretend it is something innocent. Therefore, IMO it's better that >the more common (and unprivileged) view of a process's "name" can't >readily be altered by that process. Who cares about the name? There's still /proc/*/a.out and /proc/*/path/ a.out; you can't change those. Casper _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
