On Mon, May 04, 2009 at 07:27:00PM +0200, Casper.Dik at Sun.COM wrote:
> Here's my email (for the record)
Thanks.
> Where are the changes to /proc?
>
> You cannot modify "ptools" without having the properties available through
> /proc.
My answers to these two questions are already in the case record.
> How are the CPGs recorded in a core dump?
Ah, good point. I'll go figure that out.
At first glance it looks like CPGs would appear in core files in the
form of an "ELF note" (see elfnote(), corenote(), and Pfgrab_core()),
probably in the form of an integer indicating how many CPGs, another
indicating the size of CPG type names, another indicating the size of
CPG user data, then an array of fixed sized {CPG ID, type name, user
data}.
> How are the CPGs shown through pcred? Does that work in a core dump?
I don't have code for this yet, but I'm thinking it'd be something like:
% pcred $$
17350: e/r/suid=142292 e/r/sgid=10
groups: 10 30303
CPG: krb5 123456789 [<user-data>]
CPG: audio 123456790 [<user-data>]
Yes, this would work on core files (through libproc, which will have to
know about this).
> What happens when a user su(1)s to root and then starts a daemon?
First of all they should use SMF. This applies in too many cases
already (think of resource controls, TX, ...).
It's already the case that su inherits some things that sometimes it
ought not (e.g., environment variables, unless one does su -). Passing
too many things of some kinds and not enough of others is a problem.
I'm not sure that I have a good answer (though perhaps su - should
always clear all CPGs that can be cleared in the new process).
Second, one of the CPG type semantics flags is whether a CPG should be
changed on su(1) or not. So one should think carefully when picking a
new CPG type's semantics.
Third, for CPGs that we normally want inheritted through su(1) we might
want a PAM module to change them anyways when doing becoming root. But
I'm not convinced. I think the right thing to do is to not start
daemons by hand.
Nico
--
