James Carlson wrote: > Garrett D'Amore writes: >> Reserved UIDs for this stuff is probably *not* the best solution. Some >> kind of ephemeral IDs, or a separate numbering space that is guaranteed >> not to be used with non-local services would be best. Since file >> ownerships aren't at stake, > > File ownerships are at stake, at least in the case that was originally > under discussion. They were allocating yet another UID/GID > combination, running the daemon with those values, and installing the > database that way. > > If file ownership really isn't at stake, then everyone can use a > single UID (such as the existing "noaccess" user), and the problem > goes away.
That is a non-starter for many of our customers who are looking for unique credentials for each of their services -- especially those that may be running under the same OS instance/zone. Not only does this help with accountability (syslog and audit) but having unique credentials will also help contain a compromise should one (unprivileged) service be exploited. If you were running apache and mysql (for example) as the same UID, a flaw (w/arbitrary code execution) in one could lead to the direct compromise of the other running service. Taking away proc_session from each service could help with this however. g