“在端点上授予连接为 [sa]”是什么意思做?

发布于 2025-01-07 15:05:07 字数 443 浏览 0 评论 0原文

我正在查看由 Visual Studio 数据库项目生成的脚本,我发现了这一点:

GRANT CONNECT
    ON ENDPOINT::[TSQL Default TCP] TO PUBLIC
    AS [sa];

我不知道它的作用,但它似乎以 SA 的身份授予 PUBLIC 访问权限(仅通过其读取方式)。

有人知道这到底是做什么的吗? (显然它通过“ENDPOINT”授予一些访问权限。但简单来说它有什么作用?)

通过阅读它,它告诉我任何通过 TCP 端口连接的人都可以作为 [sa] 运行。 (我希望这是不对的,但如果是的话,为什么 Visual Studio 的 DB 项目会这样做?)

I was going through the script generated by my Visual Studio Database project and I found this:

GRANT CONNECT
    ON ENDPOINT::[TSQL Default TCP] TO PUBLIC
    AS [sa];

I don't know what it does, but it seems to grant PUBLIC access as SA (just by how it reads).

Anyone know what this really does? (Clearly it grants some access via an "ENDPOINT". But in plain english what does it do?)

By just reading it, it says to me that anyone connecting via TCP port can run as [sa]. (I hope that is not right, but if it is, why would Visual Studio's DB Project do that?)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

猫烠⑼条掵仅有一顆心 2025-01-14 15:05:07

首先,由于一个明显的原因,GRANT 是不正确的:它使用受让人的名称 [PUBLIC],但它应该是 [public]。在区分大小写的安装中,该名称将无法解析。

现在关于您的问题: AS [sa] 部分与授予权限的操作相关,它不会转移给被授权者。它读起来像:

<块引用>

我以[sa]的名义,向[public]的成员授予连接到[TSQL Default TCP]端点的权限] 组。

具体来说,它并不暗示受让人([public] 的成员)将被提升为[sa]。授予连接权限是连接数据库所必需的但还不够的权限。受让人仍然需要访问数据库的权限(即,将用户映射到其在数据库中的登录名)。此外,向 [public] 服务器主体授予连接权限并不等同于为 BUILTIN\Everyone(或 BUILTIN\ANONYMOUS LOGIN 就此而言...)安全主体(或其他内置帐户)...换句话说,在 SQL Server 中没有登录名(通过 NT 组成员身份显式或隐式登录)的 NT 用户仍然无法连接到该实例。

附带说明一下,在任何全新安装上运行以下查询都会显示连接到默认 T-SQL 端点的权限已授予 [public]

select s.name as grantee, 
    e.name as endpoint,
    p.permission_name as permission,
    p.state_desc as state_desc
from sys.server_permissions p
join sys.server_principals s on s.principal_id = p.grantee_principal_id
join sys.endpoints e on p.major_id = e.endpoint_id
where p.type='CO'

To start with, the GRANT is incorrect for one obvious reason: it uses the name [PUBLIC] for the grantee, but it should be [public]. On a case sensitive installation the name will not resolve.

Now about your question: the AS [sa] part is relevant for the action of granting the permission, it does not transfer to the grantee. It reads something like:

I, in the name of [sa], grant the privilege of connecting to the [TSQL Default TCP] endpoint to the members of the [public] group.

Specifically, it does not imply that the grantee (the members of [public]) are to be elevated to [sa]. Granting connect permission is a necessary but not sufficient privileged to connect to a database. The grantee would still require the permission to access the database (ie. to have a user mapped to its login in the database). Also, granting connect permission to the [public] server principal is not equivalent to creating a login for the BUILTIN\Everyone (or BUILTIN\ANONYMOUS LOGIN for the matter...) security principals (or other built-in account)... In other words an NT user that has no login (explicit or implicit via an NT group membership) in SQL Server will still not be able to connect to the instance.

As a side note, running the following query on any brand new installation reveals that the permission to connect to the default T-SQL endpoint is already granted to [public]:

select s.name as grantee, 
    e.name as endpoint,
    p.permission_name as permission,
    p.state_desc as state_desc
from sys.server_permissions p
join sys.server_principals s on s.principal_id = p.grantee_principal_id
join sys.endpoints e on p.major_id = e.endpoint_id
where p.type='CO'
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文