From: Christian Ebner <c.ebner@proxmox.com>
To: Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>,
Hannes Laimer <h.laimer@proxmox.com>
Subject: Re: [pbs-devel] [PATCH proxmox{, -backup} 0/6] add user specific rate-limits
Date: Fri, 7 Nov 2025 08:33:53 +0100 [thread overview]
Message-ID: <862824b0-6308-43bc-8304-ed93bf186356@proxmox.com> (raw)
In-Reply-To: <20250909085245.91641-1-h.laimer@proxmox.com>
On 9/9/25 10:53 AM, Hannes Laimer wrote:
> This adds support for specifying user specific rate-limits.
> We add a user-tag to every rate-limited connection, with this present we
> can limit the connection based on the authenticated user assiciated with
> it.
>
> Authentication happens after accept, so we can't set this right when we
> accept a connection. Currently we initialize the handle on accept, we
> then give this handle to the rate_limiter callback function. And on
> completed authentication we set the user using this handle.
> I did consider using a Peer -> User map in the cache, and just adding
> entries on auth, but there isn't really a good way to clean those
> entries. And peers(so IP:port) may end up being reused, and that would
> be a problem. With the current approach we don't have this problem.
>
> Currently rules with a user specified take priority over others. So:
> user > IP only > neither, in case two rules match.
>
> If users and networks are specified, the rule only applies if both
> match. So, Any of the specified user connect from any of the specified
> network.
>
> And all of this ofc still only if the given timeframe matches.
>
> Note: this is only for users, you can't specify individual tokens. But I
> don't think that is much of a problem, it is probably even better like
> this.
>
> (I did look through BZ if there is an issue for this, I feel like there
> should be, but did not find one)
Hi,
thanks for the patches, this is a very useful feature I think.
I've planned to have a more in-depth look at this series today, but from
a first glance I see two possible issues which I think need to be addressed:
- The rate limiting happens on the RateLimitedStreams by token bucket
filtering, this however being agnostic to the traffic flowing above that
connection. And user authentication happens at request level. So while
probably not very problematic in general since there will be a dedicated
connection for different users, the same connection (TCP socket) could
be shared by multiple users, the connection is however tagged by the
first users after the first request being authenticated unless I'm
missing something. So a second user reusing the same TCP connection will
then get the limits of the first one?
- Tagging of the stream only happens *after* the first request being
processed and the response being generated. This however means that this
first request will never be limited, only subsequent requests are.
- It would probably make sense to keep the stream part as generic as
possible, the stream should not be concerned about users. So maybe it
would make sense to allow to set generic `tags` on connections, and pass
this list of tags to the rate limiter callback, so it can determine the
lowest rate limits compatible with the given tags from the ruleset. This
would still apply the same limits to users reusing the same connection,
but in a more abstract fashion.
What do you think?
_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
next prev parent reply other threads:[~2025-11-07 7:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-09 8:52 Hannes Laimer
2025-09-09 8:52 ` [pbs-devel] [PATCH proxmox 1/3] pbs-api-types: add users to traffic-control rule Hannes Laimer
2025-09-09 8:52 ` [pbs-devel] [PATCH proxmox 2/3] http: add user tag to rate-limited streams Hannes Laimer
2025-11-07 11:01 ` Christian Ebner
2025-09-09 8:52 ` [pbs-devel] [PATCH proxmox 3/3] rest-server: add use tag field to RateLimitedStreams Hannes Laimer
2025-11-07 11:12 ` Christian Ebner
2025-09-09 8:52 ` [pbs-devel] [PATCH proxmox-backup 1/3] api: taffic-control: update/delete users on rule correctly Hannes Laimer
2025-09-09 8:52 ` [pbs-devel] [PATCH proxmox-backup 2/3] traffic-control: handle users specified in a " Hannes Laimer
2025-11-07 11:20 ` Christian Ebner
2025-09-09 8:52 ` [pbs-devel] [PATCH proxmox-backup 3/3] ui: traffic-control: add users field in edit form and list Hannes Laimer
2025-11-06 9:41 ` [pbs-devel] [PATCH proxmox{, -backup} 0/6] add user specific rate-limits Hannes Laimer
2025-11-07 7:33 ` Christian Ebner [this message]
2025-11-07 7:45 ` Hannes Laimer
2025-11-07 8:16 ` Christian Ebner
2025-11-07 8:30 ` Hannes Laimer
2025-11-07 13:24 ` [pbs-devel] superseded: " Hannes Laimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=862824b0-6308-43bc-8304-ed93bf186356@proxmox.com \
--to=c.ebner@proxmox.com \
--cc=h.laimer@proxmox.com \
--cc=pbs-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox