netdev - Re: [iproute2 04/22] tc/tc_util: Read class names from provided path, /etc/, /usr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <878rba98fl.fsf@nvidia.com>
Date: Thu, 20 Jul 2023 12:10:50 +0200
From: Petr Machata <petrm@...dia.com>
To: Gioele Barabucci <gioele@...rio.it>
CC: <netdev@...r.kernel.org>, Stephen Hemminger <stephen@...workplumber.org>
Subject: Re: [iproute2 04/22] tc/tc_util: Read class names from provided
 path, /etc/, /usr


Gioele Barabucci <gioele@...rio.it> writes:

> Signed-off-by: Gioele Barabucci <gioele@...rio.it>
> ---
>  tc/tc_util.c | 18 +++++++++++++-----
>  1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/tc/tc_util.c b/tc/tc_util.c
> index ed9efa70..e6235291 100644
> --- a/tc/tc_util.c
> +++ b/tc/tc_util.c
> @@ -28,7 +28,8 @@
>  
>  static struct db_names *cls_names;
>  
> -#define NAMES_DB "/etc/iproute2/tc_cls"
> +#define NAMES_DB_USR "/usr/lib/iproute2/tc_cls"
> +#define NAMES_DB_ETC "/etc/iproute2/tc_cls"

Is there a reason that these don't use CONF_USR_DIR and CONF_ETC_DIR?
I thought maybe the caller uses those and this is just a hardcoded
fallback, but that's not the case.

>  
>  int cls_names_init(char *path)
>  {
> @@ -38,11 +39,18 @@ int cls_names_init(char *path)
>  	if (!cls_names)
>  		return -1;
>  
> -	ret = db_names_load(cls_names, path ?: NAMES_DB);
> -	if (ret == -ENOENT && path) {
> -		fprintf(stderr, "Can't open class names file: %s\n", path);
> -		return -1;
> +	if (path) {
> +		ret = db_names_load(cls_names, path);
> +		if (ret == -ENOENT) {
> +			fprintf(stderr, "Can't open class names file: %s\n", path);
> +			return -1;

The caller always calls cls_uninit(), even for failures, so this
technically does not leak. Not great, but let's keep it as is,
fixing this is clearly out of scope.

> +		}
>  	}
> +
> +	ret = db_names_load(cls_names, NAMES_DB_ETC);
> +	if (ret == -ENOENT)
> +		ret = db_names_load(cls_names, NAMES_DB_USR);
> +
>  	if (ret) {
>  		db_names_free(cls_names);
>  		cls_names = NULL;

Otherwise looking good. In fact IMHO clearer than the old code.