On Oct 6, 2014, at 11:28 AM, Bill Zeng <[email protected]> wrote:

> 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.

traffic_cop runs as root, traffic_manager retains privilege (but alters its 
effective credentials), and traffic_server drops privilege as much as possible. 
Prior to this change landing, traffic_server and traffic_manager had 
independent code paths for dropping privilege. If 
proxy.config.ssl.cert.load_elevated was used when traffic_server was built 
without POSIX capability support, it would silently fail to work.

> 
> Thanks.
> Bill
> 
> 
> On Mon, Sep 29, 2014 at 10:57 AM, James Peach <[email protected]> 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

Reply via email to