Jordan Brown wrote: > Jordan Brown wrote: >> It seems like those issues are more or less addressable... Perhaps pkg >> could check for access to the target image, and rerun itself under >> pfexec if it didn't have access (and wasn't already running as root). > > Or, alternatively, the profile could set euid=0, and pkg could reset > euid=ruid if it didn't need root to work on the selected image. > > I suppose it depends on how you feel philosophically about RBAC > authorizations and pfexec. My model of it is that the preferred model > is that the tools check authorizations and "just work" if you have the > right authorizations, and that the pf* series is a shim to allow > non-RBAC-aware commands to be used in an RBAC-ish sort of way. My model > is that if you have the authorizations, you can just use them without > taking any "extra" measures (like using pfexec or pf*sh). There is > another model where you must explicitly drink the Super Sauce to enable > your super powers... not a bad model, but I'm not sure where > authorizations fit into that model.
Personally, I want to explicitly "push the magic button" before I gain "super powers." The right solution in my view is for pkg to attempt a lock on the image that it's manipulating (which it will need to do eventually anyway to prevent multiple instances of pkg manipulating the same image at the same time). This will allow the user to know quickly if the operation they are performing *requires* them to gain additional privileges first before proceeding. Considering that there are a number of read-only operations that you can perform on an image, I am strongly against automatic privilege escalation. If users want all privileges all the time, there's always pfksh, etc. -- Shawn Walker _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
