On Fri, Aug 08, 2008 at 03:47:39PM -0400, Glenn Brunette wrote:
>
>
> 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.
Lazy people (who, me?) are likely to be using user.project as well.
Ceri
--
That must be wonderful! I don't understand it at all.
-- Moliere
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080808/387cf118/attachment.bin>
