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

Reply via email to