[Bug] ACL: DST can be accessed by SRC
Is this a support request?
- [X] This is not a support request
Is there an existing issue for this?
- [X] I have searched the existing issues
Current Behavior
my policy.json is
{
"groups": {
"group:admins": [
"abcd"
]
},
"acls": [
{
// allow admins group to access all services
"action": "accept", "src": ["group:admins"], "dst": ["*:*"]
}
]
}
The client can access(show) the admins' devies.
➜ ~ tailscale status
100.64.0.a a current_user linux idle; offers exit node
100.64.0.b b abcd iOS offline
100.64.0.c c abcd iOS offline
100.64.0.d d abcd macOS idle, tx 612 rx 252
Expected Behavior
The admins' devices shouldn't show
Steps To Reproduce
- change the
policy.json - client check the status by
tailscale status
Environment
- OS: docker
- Headscale version: 0.23.0
- Tailscale version: 1.74.0
Runtime environment
- [X] Headscale is behind a (reverse) proxy
- [X] Headscale runs in a container
Anything else?
No response
are you actually able to send traffic from the devices from current_user towards abcd or is it just that they are shown?
The output of status is only trimmed if there is no connections from either to each other, if one host can access another, but not vice versa, it will have to be in the status.
I see. Yes, you are right. abcd can ping current_user, but current_user can’t ping abcd. However, the information of abcd is shown on current_user.
C:\Users\Admin>ping 100.64.0.b
Pinging 100.64.0.b with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 100.64.0.b:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\Users\Admin>ping 100.64.0.d
Pinging 100.64.0.d with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 100.64.0.d:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\Users\Admin>tailscale status
100.64.0.a a current_user windows -
100.64.0.b b abcd iOS active; direct x.x.x.x:49501, tx 724 rx 188
100.64.0.c c abcd iOS offline
100.64.0.d d abcd macOS active; direct x.x.x.x:57392, tx 2136 rx 940
I understand the logic now, but it seems a little weird. Since abcd is the administrator, I don’t want everyone to know its information. Additionally, not only does tailscale status output abcd’s information, but the GUI of current_user also displays the hostnames under the abcd account.
I understand, but this is how it is, Tailscale does the same for the upstream software as a service.
I see. Thanks.
I have the same problem
I see. Yes, you are right.
abcdcan pingcurrent_user, butcurrent_usercan’t pingabcd. However, the information ofabcdis shown oncurrent_user.C:\Users\Admin>ping 100.64.0.b Pinging 100.64.0.b with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 100.64.0.b: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), C:\Users\Admin>ping 100.64.0.d Pinging 100.64.0.d with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 100.64.0.d: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), C:\Users\Admin>tailscale status 100.64.0.a a current_user windows - 100.64.0.b b abcd iOS active; direct x.x.x.x:49501, tx 724 rx 188 100.64.0.c c abcd iOS offline 100.64.0.d d abcd macOS active; direct x.x.x.x:57392, tx 2136 rx 940I understand the logic now, but it seems a little weird. Since
abcdis the administrator, I don’t want everyone to know its information. Additionally, not only doestailscale statusoutputabcd’s information, but the GUI ofcurrent_useralso displays the hostnames under the abcd account.
I may be wrong, I forgot to disable the firewall of 100.64.0.d. I'll double-check again.
UPDATE
- There are two users, A and B. A can access B, but B cannot access A due to ACL restrictions.
- All devices belonging to A and B appear in the output of
tailscale status. - A can ping B's devices using either the regular
pingcommand ortailscale ping. - B can only ping A's devices using
tailscale ping.
This sounds correct to me
This issue is stale because it has been open for 90 days with no activity.
This issue was closed because it has been inactive for 14 days since being marked as stale.