starred/headscale
1
0
Fork 0
mirror of https://github.com/juanfont/headscale.git synced 2026-01-12 04:10:32 +01:00
Code Issues 98 Packages Projects Releases 10 Wiki Activity

ACLs don't properly handle users #516

New Issue
Closed
opened 2025-12-29 02:19:24 +01:00 by adam · 15 comments
adam commented 2025-12-29 02:19:24 +01:00
Owner
Copy Link

Originally created by @6ixfalls on GitHub (May 26, 2023).

Originally assigned to: @kradalby on GitHub.

Bug description

While trying to use ACLs to separate users, clients, and servers, ACLs sometimes don't apply at all although the syntax is right, if using a username in the dst field of the ACL. A "fix" I found was to create a group for every single user, which obviously isn't ideal, but fixes the issue that the permission doesn't apply at all.

Environment

  • OS: Linux - Docker container
  • Headscale version: v0.22.3
  • Tailscale version: Mixed - 1.36.2, 1.42.0
  • Headscale is behind a (reverse) proxy
  • Headscale runs in a container
    I doubt this applies, I'm able to reproduce this by spinning up a new instance.

To Reproduce

{
  "acls": [
    { "action": "accept", "src": ["user1"], "dst": ["user1:*"] },
    { "action": "accept", "src": ["user2"], "dst": ["user2:*"] }
  ]
}

user1 can see & connect to all of user1's devices, while user2 has no devices to connect to, although with numerous tailscale clients. To "fix", simply add a group that only contains that user, and use it in replacement of user2.
Ex:

{
  "acls": [
    { "action": "accept", "src": ["user1"], "dst": ["user1:*"] },
    { "action": "accept", "src": ["group:user2"], "dst": ["group:user2:*"] }
  ],
  "groups": {
    "group:user2": [
      "user2"
    ]
  }
}

The first rule seems to work fine no matter what. (self to self)

Originally created by @6ixfalls on GitHub (May 26, 2023). Originally assigned to: @kradalby on GitHub. <!-- Before posting a bug report, discuss the behaviour you are expecting with the Discord community to make sure that it is truly a bug. The issue tracker is not the place to ask for support or how to set up Headscale. Bug reports without the sufficient information will be closed. Headscale is a multinational community across the globe. Our language is English. All bug reports needs to be in English. --> ## Bug description <!-- A clear and concise description of what the bug is. Describe the expected bahavior and how it is currently different. If you are unsure if it is a bug, consider discussing it on our Discord server first. --> While trying to use ACLs to separate users, clients, and servers, ACLs sometimes don't apply at all although the syntax is right, if using a username in the dst field of the ACL. A "fix" I found was to create a group for every single user, which obviously isn't ideal, but fixes the issue that the permission doesn't apply at all. ## Environment <!-- Please add relevant information about your system. For example: - Version of headscale used - Version of tailscale client - OS (e.g. Linux, Mac, Cygwin, WSL, etc.) and version - Kernel version - The relevant config parameters you used - Log output --> - OS: Linux - Docker container - Headscale version: v0.22.3 - Tailscale version: Mixed - 1.36.2, 1.42.0 <!-- We do not support running Headscale in a container nor behind a (reverse) proxy. If either of these are true for your environment, ask the community in Discord instead of filing a bug report. --> - [x] Headscale is behind a (reverse) proxy - [x] Headscale runs in a container I doubt this applies, I'm able to reproduce this by spinning up a new instance. ## To Reproduce <!-- Steps to reproduce the behavior. --> ```json { "acls": [ { "action": "accept", "src": ["user1"], "dst": ["user1:*"] }, { "action": "accept", "src": ["user2"], "dst": ["user2:*"] } ] } ``` user1 can see & connect to all of user1's devices, while user2 has no devices to connect to, although with numerous tailscale clients. To "fix", simply add a group that only contains that user, and use it in replacement of user2. Ex: ```json { "acls": [ { "action": "accept", "src": ["user1"], "dst": ["user1:*"] }, { "action": "accept", "src": ["group:user2"], "dst": ["group:user2:*"] } ], "groups": { "group:user2": [ "user2" ] } } ``` The first rule seems to work fine no matter what. (self to self)
adam added the bugno-stale-botpolicy 📝 labels 2025-12-29 02:19:24 +01:00
adam closed this issue 2025-12-29 02:19:24 +01:00
adam commented 2025-12-29 02:19:24 +01:00
Author
Owner
Copy Link

@coolrazor007 commented on GitHub (Jun 28, 2023):

I don't know if this is relevant but I'm having a similar problem. User1 nodes can't access User2 nodes devices when using groups and tags. Here's my ACL which I thought would work (also verified the tags on the nodes):

{ "groups": { "group:admin": ["user1"], "group:user2": ["user2"] }, "tagOwners": { "tag:user2": ["group:admin"], "tag:user1": ["group:admin"] }, "acls": [ { "action": "accept", "src": [ "group:admin" ], "dst": ["tag:user1:*"] }, { "action": "accept", "src": [ "group:admin", "group:user2" ], "dst": ["tag:user2:*"] } ] }

@coolrazor007 commented on GitHub (Jun 28, 2023): I don't know if this is relevant but I'm having a similar problem. User1 nodes can't access User2 nodes devices when using groups and tags. Here's my ACL which I thought would work (also verified the tags on the nodes): ` { "groups": { "group:admin": ["user1"], "group:user2": ["user2"] }, "tagOwners": { "tag:user2": ["group:admin"], "tag:user1": ["group:admin"] }, "acls": [ { "action": "accept", "src": [ "group:admin" ], "dst": ["tag:user1:*"] }, { "action": "accept", "src": [ "group:admin", "group:user2" ], "dst": ["tag:user2:*"] } ] } `
adam commented 2025-12-29 02:19:25 +01:00
Author
Owner
Copy Link

@cristihcd commented on GitHub (Jul 26, 2023):

testing the following acl with headscale v0.22.3, tailscale v1.46.0 (linux), it seems to work:

{
  "acls": [
    { "action": "accept", "src": ["user1"], "dst": ["user1:*"] },
    { "action": "accept", "src": ["user2"], "dst": ["user2:*"] }
  ]
}
  • user1 can see all user1 machines
  • user2 can see all user2 machines
  • user1 cannot see user2 machines
@cristihcd commented on GitHub (Jul 26, 2023): testing the following acl with headscale v0.22.3, tailscale v1.46.0 (linux), it seems to work: ``` { "acls": [ { "action": "accept", "src": ["user1"], "dst": ["user1:*"] }, { "action": "accept", "src": ["user2"], "dst": ["user2:*"] } ] } ``` - user1 can see all user1 machines - user2 can see all user2 machines - user1 cannot see user2 machines
adam commented 2025-12-29 02:19:25 +01:00
Author
Owner
Copy Link

@leeaash commented on GitHub (Aug 4, 2023):

testing the following acl with headscale v0.22.3, tailscale v1.46.0 (linux), it seems to work:

{
  "acls": [
    { "action": "accept", "src": ["user1"], "dst": ["user1:*"] },
    { "action": "accept", "src": ["user2"], "dst": ["user2:*"] }
  ]
}
  • user1 can see all user1 machines
  • user2 can see all user2 machines
  • user1 cannot see user2 machines

you can try to add some tag on user, then it won't work

@leeaash commented on GitHub (Aug 4, 2023): > testing the following acl with headscale v0.22.3, tailscale v1.46.0 (linux), it seems to work: > > ``` > { > "acls": [ > { "action": "accept", "src": ["user1"], "dst": ["user1:*"] }, > { "action": "accept", "src": ["user2"], "dst": ["user2:*"] } > ] > } > ``` > > * user1 can see all user1 machines > * user2 can see all user2 machines > * user1 cannot see user2 machines you can try to add some tag on user, then it won't work
adam commented 2025-12-29 02:19:25 +01:00
Author
Owner
Copy Link

@mastier commented on GitHub (Sep 15, 2023):

I confirm I see the same issue.

@mastier commented on GitHub (Sep 15, 2023): I confirm I see the same issue.
adam commented 2025-12-29 02:19:25 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Dec 24, 2023):

This issue is stale because it has been open for 90 days with no activity.

@github-actions[bot] commented on GitHub (Dec 24, 2023): This issue is stale because it has been open for 90 days with no activity.
adam commented 2025-12-29 02:19:25 +01:00
Author
Owner
Copy Link

@6ixfalls commented on GitHub (Dec 24, 2023):

Still an issue, unsure if fixed in new beta

@6ixfalls commented on GitHub (Dec 24, 2023): Still an issue, unsure if fixed in new beta
adam commented 2025-12-29 02:19:25 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Mar 25, 2024):

This issue is stale because it has been open for 90 days with no activity.

@github-actions[bot] commented on GitHub (Mar 25, 2024): This issue is stale because it has been open for 90 days with no activity.
adam commented 2025-12-29 02:19:26 +01:00
Author
Owner
Copy Link

@6ixfalls commented on GitHub (Mar 25, 2024):

Still an issue, unsure if fixed in new beta

@6ixfalls commented on GitHub (Mar 25, 2024): Still an issue, unsure if fixed in new beta
adam commented 2025-12-29 02:19:26 +01:00
Author
Owner
Copy Link

@Snuupy commented on GitHub (Apr 22, 2024):

tested beta9, tags broken

@Snuupy commented on GitHub (Apr 22, 2024): tested beta9, tags broken
adam commented 2025-12-29 02:19:26 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jul 22, 2024):

This issue is stale because it has been open for 90 days with no activity.

@github-actions[bot] commented on GitHub (Jul 22, 2024): This issue is stale because it has been open for 90 days with no activity.
adam commented 2025-12-29 02:19:26 +01:00
Author
Owner
Copy Link

@RamonAbudAlcala commented on GitHub (Jan 14, 2025):

It seems that this behaviour is inteded. Here is a video reference from Tailscale's Youtube channel.
https://youtu.be/Jn8_Sh4r8d4?t=413 I pasted the time at what this is mentioned, but most probably one needs to watch a few minutes before for context.

You need a hosts block in your file, specifying the hostname and ip address.

@RamonAbudAlcala commented on GitHub (Jan 14, 2025): It seems that this behaviour is inteded. Here is a video reference from Tailscale's Youtube channel. https://youtu.be/Jn8_Sh4r8d4?t=413 I pasted the time at what this is mentioned, but most probably one needs to watch a few minutes before for context. You need a `hosts` block in your file, specifying the hostname and ip address.
adam commented 2025-12-29 02:19:26 +01:00
Author
Owner
Copy Link

@jacobwhall commented on GitHub (Mar 25, 2025):

I am experiencing this issue using headscale 0.25.1

Accepting connections from group:jacob to group:jacob works, but doing so from jacob to jacob does not.

@jacobwhall commented on GitHub (Mar 25, 2025): I am experiencing this issue using headscale 0.25.1 Accepting connections from `group:jacob` to `group:jacob` works, but doing so from `jacob` to `jacob` does not.
adam commented 2025-12-29 02:19:26 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Apr 14, 2025):

As part of #2416, I think the v2 should address this, it will be available to test as part of a beta and I would appreciate a lot that people help test this when it is released.

@kradalby commented on GitHub (Apr 14, 2025): As part of #2416, I think the v2 should address this, it will be available to test as part of a beta and I would appreciate a lot that people help test this when it is released.
adam commented 2025-12-29 02:19:26 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (May 5, 2025):

A beta with the new policy has been released, I think it should have improved the situation and would love to hear if this is still happening. https://github.com/juanfont/headscale/releases/tag/v0.26.0-beta.1

@kradalby commented on GitHub (May 5, 2025): A beta with the new policy has been released, I think it should have improved the situation and would love to hear if this is still happening. https://github.com/juanfont/headscale/releases/tag/v0.26.0-beta.1
adam commented 2025-12-29 02:19:27 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (May 14, 2025):

Closing as fixed in the beta, if this is not the case, please open a new issue with the details we require for debugging.

@kradalby commented on GitHub (May 14, 2025): Closing as fixed in the beta, if this is not the case, please open a new issue with the details we require for debugging.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
CLI
DERP
DNS
Nix
OIDC
SSH
bug
database
documentation
duplicate
enhancement
faq
good first issue
grants
help wanted
might-come
needs design doc
needs investigation
no-stale-bot
out of scope
performance
policy 📝
pull-request
Mirrored from GitHub Pull Request
 question
regression
routes
stale
tags
tailscale-feature-gap
well described ❤️
wontfix
No Label bug no-stale-bot policy 📝
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/headscale#516
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?