Nicolas Williams wrote: >> Whether an >> operation is performed locally by the command or by a service should not >> factor into the picture, because it is an implementation detail, not >> part of the user-facing interface of the command. > > Well, when the operation is performed by a daemon then any mask-and-cape > context needs to be passed by the caller to the daemon and the daemon > needs to evaluate this carefully (i.e., it still needs to eval the > caller's euid's authorizations -- the mask-and-cape context being a > filter of those).
I understand the implementation issues, but again... whether an operation is performed directly by the command or is done by a daemon is not part of the user-facing interface for the command, while whether or not you must explicitly put on your costume *is* part of the user-facing interface. Perhaps those implementation issues would cause us to tend to prefer one model over the other as the standard, but they should not be used as a reason to have commands present different interfaces to the user. Do the printer-administration commands act directly on the queues, or do they tell the printer daemon and the printer daemon does it? I don't know, and I don't care, and it might vary from one release to the next... but the user-facing behavior should remain the same. > That also means that the caller needs some UI element > by which the user gets to choose whether to assert the authorizations > they do have. That seems annoying. Agreed. > The simplest model is to have authorizations immediately available > without having to take an explicit step. This is also potentially > surprising, Why? If you've been granted a particular super power, why should it be surprising when it works? Indeed, if you start granting yourself authorizations, you increase the probability that you will eventually shoot yourself in the foot... but that's your choice. Note also that if you *do* want to have an explicit "SHAZOOM!" step, you can grant the authorizations to a role, and assume the role when you want to be super. >> - Another local daemon? El yucko. > > It could be one started by pkg(1) itself, via setuid, though this means > that users must have plenty of privileges in their Limit set (whereas > using a service started by SMF does not impose such a restriction); a > minor problem. Er... I think you're tying yourself into a pretzel here. If pkg is setuid and starts the daemon itself, the security situation is almost the same as if it just did the operation directly. If you're willing to do to the effort to have pkg and its daemon be setuid-safe, why not just have pkg be setuid-safe, have it check authorizations, and have it execute the operation locally? ... but again, that's all an implementation detail. The architectural question is whether, when somebody has been granted the "can administer packages" authorization, they have to explicitly invoke that authorization. Whatever the answer is can clearly be implemented, for both major implementation strategies.
