All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: "Ahelenia Ziemiańska" <nabijaczleweli@nabijaczleweli.xyz>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH] conntrack: -L doesn't take a value, so don't discard one (same for -IUDGEFA)
Date: Wed, 25 Sep 2024 22:32:59 +0200	[thread overview]
Message-ID: <ZvRze9JEBJ28ityC@calendula> (raw)
In-Reply-To: <qe4cxltrompmuajfgfkedrecefkyy2eopi3erttlm7c3xigs2g@tarta.nabijaczleweli.xyz>

On Wed, Sep 25, 2024 at 05:11:01PM +0200, Ahelenia Ziemiańska wrote:
> On Wed, Sep 25, 2024 at 04:53:49PM +0200, Pablo Neira Ayuso wrote:
> > On Tue, Sep 03, 2024 at 04:53:46PM +0200, Ahelenia Ziemiańska wrote:
> > > On Tue, Sep 03, 2024 at 10:22:09AM +0200, Pablo Neira Ayuso wrote:
> > > > On Tue, Sep 03, 2024 at 04:16:21AM +0200, Ahelenia Ziemiańska wrote:
> > > > > The manual says
> > > > >    COMMANDS
> > > > >        These options specify the particular operation to perform.
> > > > >        Only one of them can be specified at any given time.
> > > > > 
> > > > >        -L --dump
> > > > >               List connection tracking or expectation table
> > > > > 
> > > > > So, naturally, "conntrack -Lo extended" should work,
> > > > > but it doesn't, it's equivalent to "conntrack -L",
> > > > > and you need "conntrack -L -o extended".
> > > > > This violates user expectations (borne of the Utility Syntax Guidelines)
> > > > > and contradicts the manual.
> > > > > 
> > > > > optarg is unused, anyway. Unclear why any of these were :: at all?
> > > > Because this supports:
> > > >         -L
> > > >         -L conntrack
> > > >         -L expect
> > > Well that's not what :: does, though; we realise this, right?
> > > 
> > > "L::" means that getopt() will return
> > >   "-L", "conntrack" -> 'L',optarg=NULL
> > >   "-Lconntrack"     -> 'L',optarg="conntrack"
> > > and the parser for -L (&c.) doesn't... use optarg.
> > Are you sure it does not use optarg?
> > 
> > static unsigned int check_type(int argc, char *argv[])
> > {
> >         const char *table = get_optional_arg(argc, argv);
> > 
> > and get_optional_arg() uses optarg.
> 
> This I've missed, but actually my diagnosis still holds:
>   static unsigned int check_type(int argc, char *argv[])
>   {
>   	const char *table = get_optional_arg(argc, argv);
>   
>   	/* default to conntrack subsystem if nothing has been specified. */
>   	if (table == NULL)
>   		return CT_TABLE_CONNTRACK;
> 
>   static char *get_optional_arg(int argc, char *argv[])
>   {
>   	char *arg = NULL;
>   
>   	/* Nasty bug or feature in getopt_long ?
>   	 * It seems that it behaves badly with optional arguments.
>   	 * Fortunately, I just stole the fix from iptables ;) */
>   	if (optarg)
>   		return arg;
> 
> So, if you say -Lanything, then
>   optarg=anything
>   get_optional_arg=(null)
> (notice that it says "return arg;", not "return optarg;",
>  i.e. this is "return NULL").
> 
> It /doesn't/ use optarg, because it explicitly treats an optarg as no optarg.
> 
> It's unclear to me what the comment is referencing,
> but I'm assuming some sort of confusion with what :: does?
> Anyway, that if(){ can be removed now, since it can never be taken now.

The issue that I'm observing is that

# conntrack -Lconntrack

now optarg is NULL after your patch, so 'conntrack' is ignored, so it
falls back to list the conntrack table.

Then, this breaks:

# conntrack -Lexpect
conntrack v1.4.9 (conntrack-tools): Bad parameter `xpect'
Try `conntrack -h' or 'conntrack --help' for more information.

Maybe your patch needs an extension to deal with this case too?

Regarding your question, this parser is old and I shamelessly took it
from the original iptables to make syntax similar.

  reply	other threads:[~2024-09-25 20:33 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-03  2:16 [PATCH] conntrack: -L doesn't take a value, so don't discard one (same for -IUDGEFA) Ahelenia Ziemiańska
2024-09-03  8:22 ` Pablo Neira Ayuso
2024-09-03 14:53   ` Ahelenia Ziemiańska
2024-09-15 21:38     ` Pablo Neira Ayuso
2024-09-25 14:53     ` Pablo Neira Ayuso
2024-09-25 15:11       ` Ahelenia Ziemiańska
2024-09-25 20:32         ` Pablo Neira Ayuso [this message]
2024-09-26  8:28           ` наб
2024-09-26 10:32             ` Pablo Neira Ayuso
2024-09-26 10:38               ` Pablo Neira Ayuso
2024-09-26 11:05                 ` наб

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=ZvRze9JEBJ28ityC@calendula \
    --to=pablo@netfilter.org \
    --cc=nabijaczleweli@nabijaczleweli.xyz \
    --cc=netfilter-devel@vger.kernel.org \
    /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.