From: Stefan Hanreich <s.hanreich@proxmox.com>
To: Robert Obkircher <r.obkircher@proxmox.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH v1 pve-firewall] fix #7068: show rule comments in iptables output
Date: Fri, 5 Dec 2025 14:58:58 +0100 [thread overview]
Message-ID: <9a96aa1e-5c19-4976-847a-3a9ce79f3ebf@proxmox.com> (raw)
In-Reply-To: <8c636f5c-72e1-4486-aa58-f35c4f6adae2@proxmox.com>
On 12/5/25 2:02 PM, Robert Obkircher wrote:
>
> On 12/5/25 12:58, Stefan Hanreich wrote:
>> Tested this in a similar vein as the nftables one:
>> * "normal" comments
>> * comments that are too long
>> * comments that are too long and do not truncate nicely at the 255
>> boundary
>> * comments in security groups
>> * emojis in comments
>>
>> afaict the PVECOMMENT: prefix is merely visual? it doesn't serve any
>> functional purpose? At least a quick monkey-patch removing it didn't
>> break anything and judging from the source code it seems fine as well.
>> Imo it would be fine then to completely omit it then (even in the case
>> where rule comments start with PVESIG).
>
> I think the parser in iptables_get_chains would at least temporarily set
> an invalid signature on the chain and only override it later because the
> real PVESIG: rule is always present and printed last. Relying on that
> seemed a bit sketchy.
Do you mean the 'unknown' signature? Seems like this happens due to this
line here in the parser callback [1]. The other regex matches only
`PVESIG:` comments anyway.
If we remove the prefix, adding a comment with a `PVESIG:` prefix would
do that, I guess?
[1]
https://git.proxmox.com/?p=pve-firewall.git;a=blob;f=src/PVE/Firewall.pm;h=93f8c34466fd61bc646439275597aa24b8718053;hb=HEAD#l2093
>>
>> mb someone with more experience with perl and utf-8 can chime in on the
>> truncation logic?
>>
>> Tested-by: Stefan Hanreich <s.hanreich@proxmox.com>
>>
>> On 12/1/25 1:33 PM, Robert Obkircher wrote:
>>> Use the iptables comment extension to include comments from the UI.
>>> Prefix them with "PVECOMMENT:" to avoid interfering with the existing
>>> "PVESIG:$sig" comments, which are used to store signatures for change
>>> detection.
>>>
>>> The total length of the (unescaped) comments is limited to 255 utf8
>>> bytes. According to the man page it could be up to 256 characters, but
>>> the actual implementation seems to zero terminate the buffer before
>>> saving. For example, the following command produces a 255 char comment
>>> ending in 'a':
>>> iptables -A PVEFW-HOST-IN -m comment --comment $(python3 -c
>>> "print('ab'*256)")
>>>
>>> Unlike the iptables command, this version truncates to valid utf8.
>>>
>>> Signed-off-by: Robert Obkircher <r.obkircher@proxmox.com>
>>> ---
>>> src/PVE/Firewall.pm | 17 ++++++++++++++++-
>>> 1 file changed, 16 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/PVE/Firewall.pm b/src/PVE/Firewall.pm
>>> index 93f8c34..688829a 100644
>>> --- a/src/PVE/Firewall.pm
>>> +++ b/src/PVE/Firewall.pm
>>> @@ -2271,6 +2271,20 @@ sub ipt_gen_src_or_dst_match {
>>> return $match;
>>> }
>>> +sub print_ipt_comment {
>>> + my ($comment) = @_;
>>> + return "" if !defined($comment) || $comment eq "";
>>> + $comment = encode("utf8", $comment, Encode::LEAVE_SRC);
>>> + $comment = "PVECOMMENT:$comment"; # avoid any confusion with
>>> PVESIG comments
>>> +
>>> + # man iptables-extensions says 256 chars, but the code only
>>> saves 255
>>> + $comment = substr($comment, 0, 255);
>>> + $comment = encode('utf8', decode('utf8', $comment,
>>> Encode::FB_QUIET | Encode::LEAVE_SRC));
>>> +
>>> + $comment =~ s/[\\"']/\\$1/g; # escape logic from
>>> xtables_save_string
seems like there is still an issue here - setting the comment `###"` I
get several:
Use of uninitialized value $1 in concatenation (.) or string at
/usr/share/perl5/PVE/Firewall.pm line 2284.
Can be easily checked via `pve-firewall compile`.
>>> + return " -m comment --comment \"$comment\""; # never omit quotes
>>> because of the colon
>>> +}
>>> +
>>> # convert a %rule to an array of iptables commands
>>> sub ipt_rule_to_cmds {
>>> my ($rule, $chain, $ipversion, $cluster_conf, $fw_conf, $vmid)
>>> = @_;
>>> @@ -2375,7 +2389,8 @@ sub ipt_rule_to_cmds {
>>> my $logaction = get_log_rule_base($chain, $vmid, $rule-
>>> >{logmsg}, $loglevel);
>>> push @iptcmds, "-A $chain $matchstr $logaction";
>>> }
>>> - push @iptcmds, "-A $chain $matchstr $targetstr";
>>> + my $comment = print_ipt_comment($rule->{comment});
>>> + push @iptcmds, "-A $chain $matchstr $targetstr$comment";
>>> return @iptcmds;
>>> }
>>>
>>
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
prev parent reply other threads:[~2025-12-05 13:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-01 12:34 Robert Obkircher
2025-12-05 11:59 ` Stefan Hanreich
2025-12-05 13:03 ` Robert Obkircher
2025-12-05 13:58 ` Stefan Hanreich [this message]
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=9a96aa1e-5c19-4976-847a-3a9ce79f3ebf@proxmox.com \
--to=s.hanreich@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
--cc=r.obkircher@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