Picking up where I left off... On Wed, May 06, 2009 at 12:02:45AM -0700, Edward Pilatowicz wrote: > - is the CPG door upcall mechanism used for anything other than a > notification for when a CPG group becomes empty? (i'm worried that > perhaps we're adopting the linux behaviour of having the kernel spawn > processes to prompt the user for information.)
Kernel consumers would be allowed to use that door for other purposes, yes, though I've not yet established the protocol for doing that. That does compare to the Linux keyring "upcall" feature, though unlike the Linux keyring upcall this scheme does not involve the kernel spawning processes. More importantly, I don't think this upcall facility should be used for prompting users so much as for accessing material not stored in the kernel, much like the NFS/RPCSEC_GSS code does in upcalling to gssd to access users' Kerberos V and DH credentials. I.e., we already have a precedent for this feature and I don't see what should be controversial about it, though I think the Linux scheme in particular is controversial. > - given that CPGs are associated with credentials, how could they > replace process project(4)s and tasks, which can contain process > with different credentials? CPGs wouldn't replace project or task IDs, but they could be moved into a CPG type. The reason for this is that a) every process has a cred_t, so we can find that process' project/task through cred_t if need be, b) CPG membership is inheritted across fork(), exec(), setuid(), etcetera, unless explicit action is taken to change CPG membership. See my other answers to others on this same point. > - you mention encoding ssh agent information in CPGs. afaik, the > current problem with ssh agent environment variables is that if > someone connects to a machine via ssh, starts the ssh agent, then logs > into the machine again via ssh, the second login session won't know > about the agent started by the first session. how can CPGs solve this > problem? That's a problem with ssh-agent that CPGs don't solve since joining an existing CPG is no simpler than finding the SSH_AUTH_SOCK env var value of another login session's processes and then setting it. > - you mention that on linux, a process may manipulate it's parents PAGs. > will this be possible for solaris? (i'm hoping the answer is no.) Yes, it is possible (and that's a feature of AFS PAGs, not so much Linux keyrings). > if it's yes, could you please site me some examples of subsystems > where a subprocess is allowed to modify it's parents properties? Such things can be done through /proc today. There's no subsystem where I think that is necessary, but that doesn't mean that it shouldn't be possible, if anything else, from a debugging perspective. In the AFS usage the reason for this facility is so that pagsh(1) can change the PAG membership of an interactive shell from which it's spawned _as though pagsh were a shell builtin_. > (i can think of examples where one process can modify another via > /proc or some -p type option, but these are all subject to priv > checks and not just blindly permitted because there is some kind of > causal relationship between the two processes.) Privileges apply here as well: you need PRIV_PROC_SESSION to change the CPG membership of processes running as you, and you need PRIV_PROC_OWNER to change the CPG membership of processes not running as you (or perhaps this latter should require all zone privs). > - cpg_chown() and cpg_chown_byid() > > please define a CPG owner. It's a UID (uid_t), specifically it should be the UID of the user whose login session the CPG is associated with. > (do CPGs have an owner that is separate > from the cred_t associated with the CPG?) Yes because CPG membership is inheritted across setuid() and friends. > when would you ever want to change the ownership of a CPG? At login and su time it should happen automatically, otherwise it should be done explcitly is the user has a need for it. In the AFS world users typically run different process groups with different Kerberos credentials (e.g., one runs with access to a ccache with a TGT for joeuser at JOESREALM and another with access to a TGT for joeuser/admin at JOESREALM, or joe at FRIENDSREALM). > what happens to all the processes bound to that CPG when it's > ownership changes? Nothing. CPG ownership relates to who can get/set CPG user data. > - it seems like there are a lot of CPG data modifier flags. are > CPG_S_SESSION_PRIVATE_DATA and CPG_S_SENSITIVE_DATA really useful? > > they require proc_session and proc_info respectively, and both > these privs are included in the basic set, so who are you actually > protecting this "private/sensitive" data from? Think sandboxing. I'm not sure that this approach is necessarily useful given security labeling. But I threw it in for completeness and as a way to explore extensibility through these semantics flags. We should remove the ones that we can't find uses for. > - a 64-byte user data field for a CPG seems small. how did you decide > on this size? is there any reason the size isn't specified when the > CPG type is created? It's arbitrary. It could be set to more, as long as it's fixed. It has to be fixed because of ucred_size(3C) (ucreds are an opaque octet string that can be passed around, and the system sets the max ucred size at boot time); alternatively the CPG user data could be left out of the ucred object. > - why bother with _CONFIG_NCPGROUPS? (it seems like it would be more > usefull to have a sysconf variable for the size of the user data if > you plan to keep it as a fixed size. using sysconf for this instead of > a define would allow for easier increases of the value in the future.) My intention is to have this be a sysconf, indeed. See above for why _CONFIG_NCPGROUPS needs to be fixed at boot time. > ------------------------------------------------------------------------------- > zones questions: > > - this worries me: > - New CPG types can be registered early at boot time in the global > zone > > why isn't the CPG type namespace unique across zones and why can't > zones create their own CPG types? I couldn't find a good reason for CPG type names to not be globally unique, but I'm willing to change this, of course. > why can CPGs only be created early in boot? please define early. Technically they can be created at any time, but you'd want them to be all registered before login services start, which is why I think they should be registered early in boot. > the cpg(1) command seems to be able to create and destroy cpg types. > will this command fail if it's run after the system is booted? No. > if CPG types can be created after boot, are there any resource limits > on CPG type creation? are there any privs to control CPG type > creation? All privs are needed to register new CPG types. The only applicable resource control is _CONFIG_NCPGROUPS (see above). > - if CPGs are used by things like kerberos, and kerberos is not enabled > in the global zone, but it is enabled for a non-global, how will the > kerberos CPG type be registered? (this also applies to other services > that may use CPGs in the future, like ssh, etc.) The gz admin has to do it (by enabling the relevant service(s)) knowing that the ngzs will need it. > - this also worries me: > CPG types will be registered in the global zone by an SMF service > per-CPG type. These services will also be able to register a door (in > the global zone and in non-global zones) that will receive upcalls > indicating CPG emptiness events. > > so global zone services are registering doors within zones? doors are > bound to paths. so how do these services deal with zones that are not > mounted, attached, installed? what happens when zones are destroyed? > are these services monitoring zone state changes? Oh that's terrible wording on my part! I meant that these services could run in the gz and ngzs, but that CPG type registration would only happen in the gz. > - what happens to CPG associations during a zlogin (and other > zone_enter() consumers). zlogin should clear them, but it's OK if that is not allowed by the CPG type's semantics. Think of audit context, which IIRC isn't changed across zone_enter() -- if a CPG type does not allow changing CPG membership once a CPG is joined, then it shouldn't be cleared across zone_enter(). But if I'm wrong about audit context inherittance across zone_enter() then I would agree all CPG memberships should be cleared across zone_enter(). Nico --
