sendnrw/netbird-docs
2
0
Fork 0
mirror of https://github.com/netbirdio/docs.git synced 2026-09-17 04:19:04 +02:00
Code Issues Packages Projects Releases Wiki Activity

Correct the profile removal and SSH authentication privilege wording (#895)

Browse Source
This commit is contained in:
Viktor Liu
2026-08-01 15:57:30 +02:00
committed by GitHub
parent fc92ecc8f3
commit ddec3c2f3c
5 changed files with 45 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/pages/client/grpc-socket.mdx
+15 -6
View File
@@ -113,7 +113,7 @@ netbird --daemon-addr tcp://127.0.0.1:41731 status
## Privileged Operations
Any local user can reach the socket, so the daemon authorizes individual operations
On the default sockets any local user can connect, so the daemon authorizes operations
by the identity of whoever calls it, read from the kernel rather than supplied by
the client: `SO_PEERCRED` on Linux, `LOCAL_PEERCRED` on macOS, and the named-pipe
client token on Windows. A caller whose identity cannot be established is refused.
@@ -127,12 +127,21 @@ they decide who may obtain a shell on the machine:
| Enable SSH root login | the caller is not privileged |
| Disable SSH authentication | the caller is not privileged |
| Change the management URL | the caller is not privileged and that profile has the SSH server enabled |
| Deregister the peer (logout, profile removal) | the caller is not privileged and that profile has the SSH server enabled |
| Deregister the peer (logout) | the caller is not privileged and that profile has the SSH server enabled |
Only the direction that creates the capability is guarded. Turning any of them off
is always allowed, and restating a value that is already set is not a change, so an
integration that submits a whole settings form does not start failing once an
administrator enables SSH.
Only the direction that creates the capability is guarded. Turning the SSH server or
root login off, and re-enabling SSH authentication, are always allowed, and restating a
value that is already set is not a change, so an integration that submits a whole
settings form does not start failing once an administrator enables SSH.
Removing a profile is not refused. An unprivileged caller removes it locally and the
daemon skips the deregistration, which leaves the peer registered on the management
server rather than detached from it.
A profile written before the SSH server flag existed counts as having it enabled,
because the daemon reads an unset flag the same way the engine does. The management URL
and deregistration guards therefore apply on those installations even though nobody
enabled SSH explicitly.
A refusal comes back as gRPC `PermissionDenied` carrying a `google.rpc.ErrorInfo`
detail, so an integration can recognise it without parsing the message: