Darren J Moffat wrote: > > Firstly webservd isn't just for a specific webserver, eg Apache or Sun > WebServer but any webserver.
Not optimal as it dilutes the isolation. If a code injection exploit shows up for Apache running as webservd I'd rather not let it trivially take down my JES Web Server running as the same user. It's been done because it is so cumbersome to add a new user that it's easier to reuse. Once packages can deliver their required user as in e.g. Linux distributions, the limitation goes away. > For the RBAC rights profiles (exec_attr(4), prof_attr(4)) then they > should be with the particular package that delivers eg the postgres > rights profiles are (or could be) specific to a given release. Yes all these (postgres, apache, mysql, etc, etc, etc) need to be able to deliver these in their packages. > Indeed, but the reason that webservd, gdm, postgres are *IN* Solaris > today is because things that use it are *IN* Solaris. That's a key observation that hopefully breaks very soon. Being "*IN*" Solaris is clear when there is 1 DVD delivering a fixed set of users & packages. When there is an IPS repository with say 20,000 packages most of which any one person will never install, the boundaries aren't so clear anymore. A default /etc/passwd with a several hundred hardcoded system users? That clearly won't work. > I know that other vendors distributions of Linux/BSD deal with this same > issue so how do (say Fedora, OpenSUSE) they package the /etc/passwd > entries versus the binaries that use them ? In debian the package installation creates the daemon user it needs (at least in the handful debian packages I've examined). Bill Sommerfeld wrote: > > > The issue of picking a unique name still exists, however. > > Yes. This is a case where a central registry is still necessary, and > where lack of structure in account names means that name collisions with > existing usage can't be entirely ruled out. > > Historically, the base passwd file delivered from ON has been that > registry, but if we move to a more decentralized packaging model we may > need to decouple the registry from the ON source tree. Some registry of names will surely be needed. Tying them to numeric uids needs to be optional as many of these don't need a fixed value (some might, I suppose, so an optional binding to uid might be useful, but should generally be avoided as nonconflicting numbers are a limited resource). In debian I see the pkg installation simply creates the user by name. -- Jyri J. Virkki - jyri.virkki at sun.com - Sun Microsystems
