Hi Sowmini, Thanks very much for the review! My apologies for the long delay in getting back to you on this. I'll try to address some of your general comments here.
On Mon, Jul 20, 2009 at 12:17:31PM -0400, [email protected] wrote: > > General: > - what is the difference between the netadm and netcfg uids? The > Brussels II project is considering setting up /sbin/ipadm as owned > by some dladm-like uid, and we had assumed this would be netadm. > Should it be netcfg? The difference is in what those two uids can do--what authorizations and profiles they get. netadm is able to do more actual management of the system: it has the Network Management, Network Autoconf, Network IPsec Management, Service Management profiles, which allow it to make the changes to system configuration that nwam needs to make. nwamd runs as the netadm user. netcfg is geared toward managing the repository: it can read/write/ refresh nwam configuration (by virtue of having the solaris.network. autoconf.* authorizations). netcfgd, which manages access to the repository, runs as the netcfg user. Ownership of /sbin/ipadm should probably just be root. Ownership of the back-end files, on the other hand, should probably be user netcfg, group netadm (we're introducing users netadm and netcfg, and group netadm). You might want to consider creating your own authorizations that cover your repository, and give those to the netcfg user. > - why is netcfgd under $SRC/cmd/cmd-inet/lib/netcfgd? Seems like this is > parallel to dlmgmtd for layer 3, so to be symmetric > with dlmgtd, shouldn't it be under $SRC/cmd/netcfgd/*? That's one argument; on the other hand, dlmgmtd is kind of the outlier. I can understand Seb's point about not liking the separate cmd-inet hierarchy; but it's my opinion that as long as $SRC/cmd/cmd-inet exists, it's more confusing to have some network-related things there, and some elsewhere. > at the very least, > it would make sense to have $SRC/cmd/cmd-inet/nwam/netcfgd and > $SRC/cmd/cmd-inet/nwam/nwamd ($SRC/cmd/cmd-inet/lib is misleading, since > I don't think these apps get installed in /lib), Actually, they do; they're in /lib/inet. /lib is the recommended place for daemons, as it should be out of root's path. /lib/inet aggregates network-related daemons to reduce clutter at the /lib level. > but I think the > cleaner solution is > $SRC/cmd/nwam/netcfgd > $SRC/cmd/nwam/nwamd > $SRC/cmd/nwam/common /* for common themes like daemonize() */ I think a libc daemonize() is coming, and is the right answer for that. Other than that, as Alan mentioned, there's not a lot of common code left. I would also not be enthusiastic about relocating the nwamd source, as that's been in the ON gate in its current location for quite some time now. Finally, I don't think now is the time to be re-working the source file structure without far more compelling reasons. > usr/src/cmd/cmd-inet/lib/netcfgd/Makefile > > - dlmgmtd runs as OWNER dladm, group sys. What are the owner/group > of netcftd (I'd guess that the owner would be netcfg- but inside the > code it seems to use netadm, and invokes getpwam etc. - why the > divergence from dlmgmtd)? netcfgd runs as user netcfg/group netadm; you can see this in the service manifest (network-netcfg.xml). I think the code you're talking about is where it creates the door. In that code, it gets the passwd entry for user netadm, and then uses that uid and gid to set the owner of the nwam door *directory*. I think making that netadm is appropriate; there are things in the dir owned by both netcfg and netadm. I do think there's a bug here, though: we're setting the directory mode to 0755, and I think it should be 0775, as netadm group members should be able to modify it. When the backend door itself is created, though, it is created with netcfgd's own uid/gid, which is netcfg/netadm. I think the remainder of your comments fell into either the libnwam section (which Alan is working on, and I think has replied to you about) or the libinetcfg section, which I'll be getting to shortly. Thanks, renee _______________________________________________ networking-discuss mailing list [email protected]
