深入解析 curl--delegation选项控制 Kerberos/GSS-API 凭据委托级别【免费下载链接】curlA command line tool and library for transferring data with URL syntax, supporting DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, MQTTS, POP3, POP3S, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET, TFTP, WS and WSS. libcurl offers a myriad of powerful features项目地址: https://gitcode.com/GitHub_Trending/cu/curl--delegation是 curl 命令行工具中一个面向 GSS/kerberosSPNEGO、Kerberos认证场景的安全开关用于限定在 HTTP/HTTPS 等协议的 Negotiate 认证过程中curl 是否允许把当前用户的凭据委托给服务端。读完本文你将掌握该选项三个级别none/policy/always的语义差异、对应的 libcurl APICURLOPT_GSSAPI_DELEGATION用法以及它在 lib/curl_gssapi.c 与 lib/vauth/spnego_sspi.c 底层的真实实现机制。本文的论述主体与命令语义依据 docs/cmdline-opts/delegation.md全部实现细节则来自当前仓库源码与单元测试。一、选项定位什么时候会用到它在浏览器与服务器的“单点登录”式认证中Kerberos/SPNEGONegotiate是一个常见方案客户端并不向服务端提交口令而是通过 KDC密钥分发中心获取一张服务票据service ticket来完成认证。委托delegation是其中的一种增强能力——客户端允许服务端代表用户去访问其他受保护的服务这通常意味着服务端会拿到一张可用于进一步请求的转发票据forwardable/可委托凭据。--delegation控制的正是这一环节。该选项在文档中的元数据为HelpGSS-API delegation permissionProtocolsGSS/kerberosCategoryauthAdded7.22.0即该选项自 curl 7.22.0 起提供Multisingle单值开关作用于整个命令行不能针对不同 URL 设置不同级别Example--delegation none $URL从这些元数据可以看出只有当认证走 GSS-API/kerberos 路径例如配合--negotiate使用时该选项才有意义同时它是一个安全敏感项默认行为刻意保守拒绝委托。二、三个级别none / policy / always--delegation接受一个参数LEVEL文档定义了三个取值含义层层递进LEVEL文档语义对应源码常量include/curl/curl.h说明none不允许任何委托CURLGSSAPI_DELEGATION_NONE0L默认值仅完成认证本身policy仅当 Kerberos 服务票据中置位了 OK-AS-DELEGATE 标志时才委托CURLGSSAPI_DELEGATION_POLICY_FLAG1L0是否允许委托由 realm域策略决定客户端把裁决权交给服务票据always无条件允许服务端委托CURLGSSAPI_DELEGATION_FLAG1L1总是申请可转发凭据风险最高none——安全默认none是缺省行为代表“绝不做凭据委托”。此时 curl 只提交最小化的认证凭据完成身份验证服务端无法借这些凭据去冒充用户访问其他服务。凡是拿不准委托策略、或仅需完成资源访问的场景都应保持该默认值。policy——跟随 realm 策略policy引入了一个关键概念OK-AS-DELEGATE 标志。这是 Kerberos 服务票据中的策略位由票据签发方KDC根据该服务在 realm 中是否被配置为“可被委托”来决定是否置位。采用该级别时curl 会向 GSS 库申请“策略允许时再委托”最终是否真的发生委托取决于票据而不是客户端单方面决定——所以文档将其描述为“matters of realm policy”。always——无条件委托always表示客户端无条件地请求可委托凭据并把决定权交给服务端不受票据中 OK-AS-DELEGATE 的约束。这在需要级联访问例如一个服务为了完成用户请求需要进一步调用内部 API时是必要的但由于等价于把用户凭据的能力“借”给了服务端是三者中安全边界最弱的一个。三、命令行用法与参数解析用法与 curl 其他开关一致LEVEL 写在选项之后# 最保守与不写该选项等价 curl --negotiate --delegation none https://example.com/secure # 仅当服务票据 OK-AS-DELEGATE 被置位时才允许委托 curl --negotiate --delegation policy https://example.com/secure # 无条件允许服务端委托 curl --negotiate --delegation always https://example.com/secure参数如何被解析curl 命令行的参数表把该选项注册为C_DELEGATION处理分支见 src/tool_getparam.ccase C_DELEGATION: /* --delegation */ config-gssapi_delegation delegation(nextarg);其中delegation()定义在 src/tool_paramhlp.c是典型的“字符串 → 枚举常量”映射器long delegation(const char *str) { if(curl_strequal(none, str)) return CURLGSSAPI_DELEGATION_NONE; if(curl_strequal(policy, str)) return CURLGSSAPI_DELEGATION_POLICY_FLAG; if(curl_strequal(always, str)) return CURLGSSAPI_DELEGATION_FLAG; warnf(unrecognized delegation method %s, using none, str); return CURLGSSAPI_DELEGATION_NONE; }两个值得注意的细节比较使用curl_strequal()即大小写不敏感--delegation ALWAYS与--delegation always等价若传入了三个取值以外的字符串curl 不会报错中断而是打印unrecognized delegation method xxx, using none警告并回退到none——这延续了 curl “参数不合法时采用安全默认值”的一贯风格。解析得到的值最终存入命令行运行配置结构的gssapi_delegation长整型字段见 src/tool_cfgable.h。四、库层面的对应CURLOPT_GSSAPI_DELEGATION该命令行选项在 libcurl API 中对应CURLOPT_GSSAPI_DELEGATION枚举值为210见 include/curl/curl.h。在源码内部又以易于理解的常量形式出现CURLGSSAPI_DELEGATION_NONE0CURLGSSAPI_DELEGATION_POLICY_FLAGbit 0CURLGSSAPI_DELEGATION_FLAGbit 1也就是说policy与always分别是两个独立的位标志理论上可以被同时置位含义即“策略允许时委托且总是也申请委托”语义上等价于两者取并集。采用 C 接口时典型写法为curl_easy_setopt(easy, CURLOPT_GSSAPI_DELEGATION, CURLGSSAPI_DELEGATION_FLAG); /* 等价于 --delegation always */setopt 处的位掩码校验设置入口在 lib/setopt.c实现会对传入值做一次“白名单过滤”保证内部字段里只可能残留这两个已知位case CURLOPT_GSSAPI_DELEGATION: s-gssapi_delegation (unsigned char)arg (CURLGSSAPI_DELEGATION_POLICY_FLAG | CURLGSSAPI_DELEGATION_FLAG); break;所以即使调用方传入0xFF这类非法位组合落在内部状态里的也只有POLICY_FLAG与FLAG两个 bit 的合法子集。内部存储与连接级传递该值存储于data-set.gssapi_delegation见 lib/urldata.h并在连接建立时被拷贝到连接相关的conn-gssapi_delegation字段lib/url.c从而在整个认证握手周期内可用。--libcurl 代码生成若使用--libcurl file让 curl 输出等效的 C 代码它会按 src/config2setopts.c 中的映射把命令行配置翻译为对应的 setopt 调用if(config-gssapi_delegation) my_setopt_long(curl, CURLOPT_GSSAPI_DELEGATION, config-gssapi_delegation);五、底层原理委托标志如何进入 GSS/SSPI 握手理解了参数如何被解析、存储之后最值得深挖的问题是这些标志究竟在何处、以何种形式影响真实的认证过程GSS-API 路径请求标志的构造在 Unix 系平台SPNEGO/Kerberos 走 GSS-API 实现核心逻辑在 lib/curl_gssapi.c 的gss_init_sec_context封装里。代码首先初始化基础请求标志OM_uint32 req_flags GSS_C_REPLAY_FLAG; if(mutual_auth) req_flags | GSS_C_MUTUAL_FLAG;随后依据配置逐位叠加委托相关标志if(data-set.gssapi_delegation CURLGSSAPI_DELEGATION_POLICY_FLAG) { #ifdef GSS_C_DELEG_POLICY_FLAG /* MIT Kerberos 1.7 (2009-06-02), Apple GSS, missing from GNU GSS */ req_flags | GSS_C_DELEG_POLICY_FLAG; #else infof(data, WARNING: support for CURLGSSAPI_DELEGATION_POLICY_FLAG not compiled in); #endif } if(data-set.gssapi_delegation CURLGSSAPI_DELEGATION_FLAG) req_flags | GSS_C_DELEG_FLAG;这段代码给出了“policy”级别的精确定义它不是无条件申请转发票据而是设置GSS_C_DELEG_POLICY_FLAG最终由 GSS 机制根据服务票据中的 OK-AS-DELEGATE 标志决定是否真正委托——这正是文档中“matters of realm policy”的底层含义。而“always”则对应直接设置GSS_C_DELEG_FLAG。值得留意代码中的条件编译注释GSS_C_DELEG_POLICY_FLAG需要 MIT Kerberos 1.72009-06-02或 Apple GSS 才定义GNU GSS 库缺少该常量。在缺少该常量的构建环境下即使命令行传了--delegation policycurl 也只会打印一条警告并继续不会真正申请策略型委托——因此实际行为存在明显的平台/GSS 实现差异。SSPI 路径Windows 下的实现在 Windows 平台SPNEGO 走 SSPISecurity Support Provider Interface其委托判断位于 lib/vauth/spnego_sspi.c 附近代码同样检查data-set.gssapi_delegation是否包含CURLGSSAPI_DELEGATION_FLAG命中则在向系统申请的上下文属性中开启相应的委托delegate能力。也就是说“always 无条件委托”这一语义在两个平台的后端实现中都得到了一致贯彻。六、测试覆盖三个级别的存取验证仓库用单元测试锁定了该选项在库层的语义见 tests/unit/unit3302.c。该测试的前提是构建时启用了HAVE_GSSAPI或USE_WINDOWS_SSPI其断言要点包括单独设置CURLGSSAPI_DELEGATION_FLAGeasy-set.gssapi_delegation必须等于该标志对应always单独设置CURLGSSAPI_DELEGATION_POLICY_FLAG内部字段必须等于该标志对应policy同时设置两个标志时内部字段应保持两者的并集——这印证了上文关于“policy 与 always 是正交位标志、可以叠加”的源码分析设置CURLGSSAPI_DELEGATION_NONE0后内部字段被清零即“none 即回到无委托状态”传入未知位组合如0xFF时setopt 返回成功且仅保留掩码允许的位——对应 lib/setopt.c 中位掩码过滤的实现。这套测试从 API 层把“none 清空 / policy 存 policy 位 / always 存 always 位 / 非法位被丢弃”的行为固定下来与命令行解析函数delegation()的结果一一对应。七、安全建议与适用边界综合 docs/cmdline-opts/delegation.md 的语义与上文源码分析给出如下实践建议默认保持none。绝大多数“只访问某个受保护资源”的请求不需要委托能力保持默认即可把凭据暴露面降到最低。仅在服务确有级联访问需求时再放开且优先尝试policy如果目标服务在 Kerberos realm 中已被管理员配置为“可委托”票据带 OK-AS-DELEGATE 标志policy足以工作这样即便服务被攻破也仍然受 realm 策略约束。always只在完全信任目标服务的受控网络中使用。它意味着你把“可代表用户行动”的能力无条件交给了服务端属于高信任假设应避免指向不可信主机。留意平台差异policy级别在缺少GSS_C_DELEG_POLICY_FLAG的 GSS 库如 GNU GSS上编译时无法真正生效相关构建环境会看到一条WARNING: support for ... not compiled in的日志lib/curl_gssapi.c此时应以实测行为为准。与 TLS 一起考虑委托依赖凭据的完整传输链路务必配合 HTTPS如--ssl/https://使用避免 GSS 令牌经明文通道暴露——这也是该文档See-also中关联--insecure与 ssl 相关选项的原因。若必须关闭证书校验请参考 --insecure但请先评估降级风险。结语--delegation虽然在 curl 全部参数中显得不起眼却是 Negotiate/Kerberos 单点登录体系里控制“凭据借用边界”的关键旋钮。从本文的梳理可以看到命令行层由 delegation() 完成三档字符串到位标志的映射API 层由 setopt.c 做位掩码白名单校验而真正决定安全边界的是握手阶段 curl_gssapi.c 与 spnego_sspi.c 中请求标志的构造逻辑。理解none/policy/always与 OK-AS-DELEGATE 票据标志之间的关系就能在“功能可用”与“凭据安全”之间做出有依据的取舍。【免费下载链接】curlA command line tool and library for transferring data with URL syntax, supporting DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, MQTTS, POP3, POP3S, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET, TFTP, WS and WSS. libcurl offers a myriad of powerful features项目地址: https://gitcode.com/GitHub_Trending/cu/curl创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
深入解析 curl--delegation选项控制 Kerberos/GSS-API 凭据委托级别【免费下载链接】curlA command line tool and library for transferring data with URL syntax, supporting DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, MQTTS, POP3, POP3S, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET, TFTP, WS and WSS. libcurl offers a myriad of powerful features项目地址: https://gitcode.com/GitHub_Trending/cu/curl--delegation是 curl 命令行工具中一个面向 GSS/kerberosSPNEGO、Kerberos认证场景的安全开关用于限定在 HTTP/HTTPS 等协议的 Negotiate 认证过程中curl 是否允许把当前用户的凭据委托给服务端。读完本文你将掌握该选项三个级别none/policy/always的语义差异、对应的 libcurl APICURLOPT_GSSAPI_DELEGATION用法以及它在 lib/curl_gssapi.c 与 lib/vauth/spnego_sspi.c 底层的真实实现机制。本文的论述主体与命令语义依据 docs/cmdline-opts/delegation.md全部实现细节则来自当前仓库源码与单元测试。一、选项定位什么时候会用到它在浏览器与服务器的“单点登录”式认证中Kerberos/SPNEGONegotiate是一个常见方案客户端并不向服务端提交口令而是通过 KDC密钥分发中心获取一张服务票据service ticket来完成认证。委托delegation是其中的一种增强能力——客户端允许服务端代表用户去访问其他受保护的服务这通常意味着服务端会拿到一张可用于进一步请求的转发票据forwardable/可委托凭据。--delegation控制的正是这一环节。该选项在文档中的元数据为HelpGSS-API delegation permissionProtocolsGSS/kerberosCategoryauthAdded7.22.0即该选项自 curl 7.22.0 起提供Multisingle单值开关作用于整个命令行不能针对不同 URL 设置不同级别Example--delegation none $URL从这些元数据可以看出只有当认证走 GSS-API/kerberos 路径例如配合--negotiate使用时该选项才有意义同时它是一个安全敏感项默认行为刻意保守拒绝委托。二、三个级别none / policy / always--delegation接受一个参数LEVEL文档定义了三个取值含义层层递进LEVEL文档语义对应源码常量include/curl/curl.h说明none不允许任何委托CURLGSSAPI_DELEGATION_NONE0L默认值仅完成认证本身policy仅当 Kerberos 服务票据中置位了 OK-AS-DELEGATE 标志时才委托CURLGSSAPI_DELEGATION_POLICY_FLAG1L0是否允许委托由 realm域策略决定客户端把裁决权交给服务票据always无条件允许服务端委托CURLGSSAPI_DELEGATION_FLAG1L1总是申请可转发凭据风险最高none——安全默认none是缺省行为代表“绝不做凭据委托”。此时 curl 只提交最小化的认证凭据完成身份验证服务端无法借这些凭据去冒充用户访问其他服务。凡是拿不准委托策略、或仅需完成资源访问的场景都应保持该默认值。policy——跟随 realm 策略policy引入了一个关键概念OK-AS-DELEGATE 标志。这是 Kerberos 服务票据中的策略位由票据签发方KDC根据该服务在 realm 中是否被配置为“可被委托”来决定是否置位。采用该级别时curl 会向 GSS 库申请“策略允许时再委托”最终是否真的发生委托取决于票据而不是客户端单方面决定——所以文档将其描述为“matters of realm policy”。always——无条件委托always表示客户端无条件地请求可委托凭据并把决定权交给服务端不受票据中 OK-AS-DELEGATE 的约束。这在需要级联访问例如一个服务为了完成用户请求需要进一步调用内部 API时是必要的但由于等价于把用户凭据的能力“借”给了服务端是三者中安全边界最弱的一个。三、命令行用法与参数解析用法与 curl 其他开关一致LEVEL 写在选项之后# 最保守与不写该选项等价 curl --negotiate --delegation none https://example.com/secure # 仅当服务票据 OK-AS-DELEGATE 被置位时才允许委托 curl --negotiate --delegation policy https://example.com/secure # 无条件允许服务端委托 curl --negotiate --delegation always https://example.com/secure参数如何被解析curl 命令行的参数表把该选项注册为C_DELEGATION处理分支见 src/tool_getparam.ccase C_DELEGATION: /* --delegation */ config-gssapi_delegation delegation(nextarg);其中delegation()定义在 src/tool_paramhlp.c是典型的“字符串 → 枚举常量”映射器long delegation(const char *str) { if(curl_strequal(none, str)) return CURLGSSAPI_DELEGATION_NONE; if(curl_strequal(policy, str)) return CURLGSSAPI_DELEGATION_POLICY_FLAG; if(curl_strequal(always, str)) return CURLGSSAPI_DELEGATION_FLAG; warnf(unrecognized delegation method %s, using none, str); return CURLGSSAPI_DELEGATION_NONE; }两个值得注意的细节比较使用curl_strequal()即大小写不敏感--delegation ALWAYS与--delegation always等价若传入了三个取值以外的字符串curl 不会报错中断而是打印unrecognized delegation method xxx, using none警告并回退到none——这延续了 curl “参数不合法时采用安全默认值”的一贯风格。解析得到的值最终存入命令行运行配置结构的gssapi_delegation长整型字段见 src/tool_cfgable.h。四、库层面的对应CURLOPT_GSSAPI_DELEGATION该命令行选项在 libcurl API 中对应CURLOPT_GSSAPI_DELEGATION枚举值为210见 include/curl/curl.h。在源码内部又以易于理解的常量形式出现CURLGSSAPI_DELEGATION_NONE0CURLGSSAPI_DELEGATION_POLICY_FLAGbit 0CURLGSSAPI_DELEGATION_FLAGbit 1也就是说policy与always分别是两个独立的位标志理论上可以被同时置位含义即“策略允许时委托且总是也申请委托”语义上等价于两者取并集。采用 C 接口时典型写法为curl_easy_setopt(easy, CURLOPT_GSSAPI_DELEGATION, CURLGSSAPI_DELEGATION_FLAG); /* 等价于 --delegation always */setopt 处的位掩码校验设置入口在 lib/setopt.c实现会对传入值做一次“白名单过滤”保证内部字段里只可能残留这两个已知位case CURLOPT_GSSAPI_DELEGATION: s-gssapi_delegation (unsigned char)arg (CURLGSSAPI_DELEGATION_POLICY_FLAG | CURLGSSAPI_DELEGATION_FLAG); break;所以即使调用方传入0xFF这类非法位组合落在内部状态里的也只有POLICY_FLAG与FLAG两个 bit 的合法子集。内部存储与连接级传递该值存储于data-set.gssapi_delegation见 lib/urldata.h并在连接建立时被拷贝到连接相关的conn-gssapi_delegation字段lib/url.c从而在整个认证握手周期内可用。--libcurl 代码生成若使用--libcurl file让 curl 输出等效的 C 代码它会按 src/config2setopts.c 中的映射把命令行配置翻译为对应的 setopt 调用if(config-gssapi_delegation) my_setopt_long(curl, CURLOPT_GSSAPI_DELEGATION, config-gssapi_delegation);五、底层原理委托标志如何进入 GSS/SSPI 握手理解了参数如何被解析、存储之后最值得深挖的问题是这些标志究竟在何处、以何种形式影响真实的认证过程GSS-API 路径请求标志的构造在 Unix 系平台SPNEGO/Kerberos 走 GSS-API 实现核心逻辑在 lib/curl_gssapi.c 的gss_init_sec_context封装里。代码首先初始化基础请求标志OM_uint32 req_flags GSS_C_REPLAY_FLAG; if(mutual_auth) req_flags | GSS_C_MUTUAL_FLAG;随后依据配置逐位叠加委托相关标志if(data-set.gssapi_delegation CURLGSSAPI_DELEGATION_POLICY_FLAG) { #ifdef GSS_C_DELEG_POLICY_FLAG /* MIT Kerberos 1.7 (2009-06-02), Apple GSS, missing from GNU GSS */ req_flags | GSS_C_DELEG_POLICY_FLAG; #else infof(data, WARNING: support for CURLGSSAPI_DELEGATION_POLICY_FLAG not compiled in); #endif } if(data-set.gssapi_delegation CURLGSSAPI_DELEGATION_FLAG) req_flags | GSS_C_DELEG_FLAG;这段代码给出了“policy”级别的精确定义它不是无条件申请转发票据而是设置GSS_C_DELEG_POLICY_FLAG最终由 GSS 机制根据服务票据中的 OK-AS-DELEGATE 标志决定是否真正委托——这正是文档中“matters of realm policy”的底层含义。而“always”则对应直接设置GSS_C_DELEG_FLAG。值得留意代码中的条件编译注释GSS_C_DELEG_POLICY_FLAG需要 MIT Kerberos 1.72009-06-02或 Apple GSS 才定义GNU GSS 库缺少该常量。在缺少该常量的构建环境下即使命令行传了--delegation policycurl 也只会打印一条警告并继续不会真正申请策略型委托——因此实际行为存在明显的平台/GSS 实现差异。SSPI 路径Windows 下的实现在 Windows 平台SPNEGO 走 SSPISecurity Support Provider Interface其委托判断位于 lib/vauth/spnego_sspi.c 附近代码同样检查data-set.gssapi_delegation是否包含CURLGSSAPI_DELEGATION_FLAG命中则在向系统申请的上下文属性中开启相应的委托delegate能力。也就是说“always 无条件委托”这一语义在两个平台的后端实现中都得到了一致贯彻。六、测试覆盖三个级别的存取验证仓库用单元测试锁定了该选项在库层的语义见 tests/unit/unit3302.c。该测试的前提是构建时启用了HAVE_GSSAPI或USE_WINDOWS_SSPI其断言要点包括单独设置CURLGSSAPI_DELEGATION_FLAGeasy-set.gssapi_delegation必须等于该标志对应always单独设置CURLGSSAPI_DELEGATION_POLICY_FLAG内部字段必须等于该标志对应policy同时设置两个标志时内部字段应保持两者的并集——这印证了上文关于“policy 与 always 是正交位标志、可以叠加”的源码分析设置CURLGSSAPI_DELEGATION_NONE0后内部字段被清零即“none 即回到无委托状态”传入未知位组合如0xFF时setopt 返回成功且仅保留掩码允许的位——对应 lib/setopt.c 中位掩码过滤的实现。这套测试从 API 层把“none 清空 / policy 存 policy 位 / always 存 always 位 / 非法位被丢弃”的行为固定下来与命令行解析函数delegation()的结果一一对应。七、安全建议与适用边界综合 docs/cmdline-opts/delegation.md 的语义与上文源码分析给出如下实践建议默认保持none。绝大多数“只访问某个受保护资源”的请求不需要委托能力保持默认即可把凭据暴露面降到最低。仅在服务确有级联访问需求时再放开且优先尝试policy如果目标服务在 Kerberos realm 中已被管理员配置为“可委托”票据带 OK-AS-DELEGATE 标志policy足以工作这样即便服务被攻破也仍然受 realm 策略约束。always只在完全信任目标服务的受控网络中使用。它意味着你把“可代表用户行动”的能力无条件交给了服务端属于高信任假设应避免指向不可信主机。留意平台差异policy级别在缺少GSS_C_DELEG_POLICY_FLAG的 GSS 库如 GNU GSS上编译时无法真正生效相关构建环境会看到一条WARNING: support for ... not compiled in的日志lib/curl_gssapi.c此时应以实测行为为准。与 TLS 一起考虑委托依赖凭据的完整传输链路务必配合 HTTPS如--ssl/https://使用避免 GSS 令牌经明文通道暴露——这也是该文档See-also中关联--insecure与 ssl 相关选项的原因。若必须关闭证书校验请参考 --insecure但请先评估降级风险。结语--delegation虽然在 curl 全部参数中显得不起眼却是 Negotiate/Kerberos 单点登录体系里控制“凭据借用边界”的关键旋钮。从本文的梳理可以看到命令行层由 delegation() 完成三档字符串到位标志的映射API 层由 setopt.c 做位掩码白名单校验而真正决定安全边界的是握手阶段 curl_gssapi.c 与 spnego_sspi.c 中请求标志的构造逻辑。理解none/policy/always与 OK-AS-DELEGATE 票据标志之间的关系就能在“功能可用”与“凭据安全”之间做出有依据的取舍。【免费下载链接】curlA command line tool and library for transferring data with URL syntax, supporting DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, MQTTS, POP3, POP3S, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET, TFTP, WS and WSS. libcurl offers a myriad of powerful features项目地址: https://gitcode.com/GitHub_Trending/cu/curl创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
` 与 `/df` 接口深度解析)
