From: Hannes Laimer <h.laimer@proxmox.com>
To: Christian Ebner <c.ebner@proxmox.com>,
Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>
Subject: Re: [pbs-devel] [PATCH proxmox{, -backup} 0/6] add user specific rate-limits
Date: Fri, 7 Nov 2025 08:45:09 +0100 [thread overview]
Message-ID: <ff369d04-49f7-4fab-919b-dea6a6fe1840@proxmox.com> (raw)
In-Reply-To: <862824b0-6308-43bc-8304-ed93bf186356@proxmox.com>
On 11/7/25 08:33, Christian Ebner wrote:
> 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:
>
Thanks for taking a look!
> - 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?
Is that actually possible? I assumed new auth implies a new
connection(so the thing we tagged here). So a user could connect to the
PBS and not go through .accept() by the server?
Or do you mean after one connection is done a later one could end up
reusing the same port? In that case it would have to be accepted first
and go through auth again, no?
> - 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.
well, we can't before auth, we don't know who it is we're talking to,
no?
> - 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.
I did think about that, but I couldn't really come up with much of a
usecase. User is the only one I could think of that can't be done on
accept but has to be done after auth. But there may very well be some,
I just couldn't really think of any.
>
> 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:45 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
2025-11-07 7:45 ` Hannes Laimer [this message]
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=ff369d04-49f7-4fab-919b-dea6a6fe1840@proxmox.com \
--to=h.laimer@proxmox.com \
--cc=c.ebner@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.