Re: [iptables PATCH 4/4] nft: Fix EPERM handling for extensions without rev 0

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Thu, May 05, 2022 at 02:09:52PM +0200, Phil Sutter wrote:
> On Wed, May 04, 2022 at 10:17:21PM +0200, Pablo Neira Ayuso wrote:
> > On Wed, May 04, 2022 at 12:34:16PM +0200, Phil Sutter wrote:
> > > Treating revision 0 as compatible in EPERM case works fine as long as
> > > there is a revision 0 of that extension defined in DSO. Fix the code for
> > > others: Extend the EPERM handling to all revisions and keep the existing
> > > warning for revision 0.
> > > 
> > > Fixes: 17534cb18ed0a ("Improve error messages for unsupported extensions")
> > > Signed-off-by: Phil Sutter <phil@nwl.cc>
> > > ---
> > >  iptables/nft.c                                     | 14 ++++++++++----
> > >  .../shell/testcases/iptables/0008-unprivileged_0   |  6 ++++++
> > >  2 files changed, 16 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/iptables/nft.c b/iptables/nft.c
> > > index 33813ce1b9202..95e6c222682c0 100644
> > > --- a/iptables/nft.c
> > > +++ b/iptables/nft.c
> > > @@ -3510,15 +3510,21 @@ int nft_compatible_revision(const char *name, uint8_t rev, int opt)
> > >  err:
> > >  	mnl_socket_close(nl);
> > >  
> > > -	/* pretend revision 0 is valid -
> > > +	/* ignore EPERM and errors for revision 0 -
> > >  	 * this is required for printing extension help texts as user, also
> > >  	 * helps error messaging on unavailable kernel extension */
> > > -	if (ret < 0 && rev == 0) {
> > > -		if (errno != EPERM)
> > > +	if (ret < 0) {
> > > +		if (errno == EPERM) {
> > > +			fprintf(stderr,
> > > +				"%s: Could not determine whether revision %u is supported, assuming it is.\n",
> > 
> > I'm not sure the user can do much about this error message, to me the
> > revisions concept are developer-only, I don't think we expose this
> > implementation detail in the documentation.
> > 
> > Why warn users in this case?
> 
> You're right, it does not make much sense to be verbose here. I copied
> that error message from libxtables, iptables-legacy does the same if
> socket() fails with EPERM during compatibility check for revisions != 0.
> 
> WDYT, drop both? Leave the one in libxtables alone "for legacy
> purposes"?
> 
> I'd make them debug output, but nft_compatible_revision() does not have
> access to nft_handle which I can't easily change since it is a callback
> in xtables_globals.

If you needs this maybe you can do this before release, there is a
bump in libversion for recent updates in iptables, unless some recent
updates are reworked to be added into xshared.c (at the cost of
slightly increasing size of xtables-multi binaries).

Your call.