On 02/12/13 05:39 AM, Danek Duvall wrote:
I don't like needing to use 'all' privileges, but they're necessary in
order to keep /system/volatile as our temporary directory; the
alternative of using a known-location in /tmp would be worse imho.
Sorry I'm getting to this so late, but couldn't we use mwac to limit reduce
the privileges below "all": "{zone}:/system/volatile/<dir>"? If"<dir>"
isn't a fixed directory, we'd still need some shenanigans to drop privs
from writing /system/volatile, but either way it'd be safer than "all".
Yep, I had tried that before submitting the code review - I believe we
were running into this restriction, documented in privileges(5)
PRIV_FILE_DAC_WRITE
Allow a process to write a file or directory whose per-
mission bits or ACL do not allow the process write per-
mission. All privileges are required to write files
owned by UID 0 in the absence of an effective UID of 0.
Since /system/volatile is owned by root, we can't write it even with, eg.
{file_dac_write}:/system/volatile,{file_dac_write}:/system/volatile/*
Another way to solve the problem would be if SMF supported Profiles in
its <method_context> elements. Then, we could create a special profile
that (only) allows a given command to run as euid=0, then we could run
/usr/lib/pkg.depot-config or /usr/lib/pkg.sysrepo using pfexec, and
leave the rest of the method script to run as pkg5srv.
In the code I putback, we're close to that: as soon as we've run
pkg.sysrepo or pkg.depot-config, we use ppriv -s to drop privileges.
If we want more security, the only other option I can think of is to use
a separate SMF service that runs as root (or has 'all' privileges) to
'mkdir /system/volatile/pkg' and chown it to pkg5srv, but I'm convinced
that adding another SMF service is really worth it here.
cheers,
tim
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
