Hi James, Can you elaborate on the inconsistency problems a little bit more? To my understanding, traffic_cop runs as root. traffic_manager and traffic_server run as unprivileged nobody.
Thanks. Bill On Mon, Sep 29, 2014 at 10:57 AM, James Peach <jpe...@apache.org> wrote: > Hi all, > > I've been looking at the way Traffic Server elevated privilege, and it's > quite inconsistent right now, and it doesn't work correctly in all > configurations. I am working on making this consistent. Here is the > behavior I plan to implement: > > 1. traffic_manager runs with real root credentials, but > effective credentials as given by proxy.config.admin.user_id. > It will elevate back to root to perform privileged operations. > > 2. traffic_server is started with real root credentials, > but attempts to permanently drop to an unprivileged user early > in the startup process. The unprivileged user account for > traffic_server is also given by proxy.config.admin.user_id. > when traffic_server drops privilege, it does so permanently. > > 3. traffic_server may elevate privilege depending on the > value of proxy.config.ssl.cert.load_elevated and > proxy.config.plugin.load_elevated. This elevation will only > be supported on platforms that have per-thread capabilities. > traffic_server will check at startup whether to retain > sufficient capabilities to allow it to elevate later. This > means that the *.load_elevated configurations will not be > reloadable. > > 4. After traffic_server drops privilege, we will continue to abort > with a fatal error if the real or effective user ID is root. This > behavior can be avoided by defining BIG_SECURITY_HOLE=1 at build > time. > > Note that people on #traffic-server seemed to agree that we should move > away from allowing traffic_server to retain privilege. I the future, I hope > that we can call up to traffic_manager to perform any privileged > operations, and stop supporting root privileges fot plugins. > > cheers, > James
