linux-kernel - Re: [PATCH v4 1/3] initramfs: add file metadata

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: <20220615175412.GA7029@lxhi-065>
Date:   Wed, 15 Jun 2022 19:54:12 +0200
From:   Eugeniu Rosca <erosca@...adit-jv.com>
To:     Roberto Sassu <roberto.sassu@...wei.com>,
        Mimi Zohar <zohar@...ux.vnet.ibm.com>
CC:     <viro@...iv.linux.org.uk>, <linux-security-module@...r.kernel.org>,
        <linux-integrity@...r.kernel.org>, <initramfs@...r.kernel.org>,
        <linux-api@...r.kernel.org>, <linux-fsdevel@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <bug-cpio@....org>,
        <silviu.vlasceanu@...wei.com>, <dmitry.kasatkin@...wei.com>,
        <takondra@...co.com>, <kamensky@...co.com>, <hpa@...or.com>,
        <arnd@...db.de>, <rob@...dley.net>, <james.w.mcmechan@...il.com>,
        <niveditas98@...il.com>, Dirk Behme <dirk.behme@...bosch.com>,
        Eugeniu Rosca <erosca@...adit-jv.com>,
        Eugeniu Rosca <roscaeugeniu@...il.com>
Subject: Re: [PATCH v4 1/3] initramfs: add file metadata

Hello Roberto,
Hello Mimi,

On Thu, May 23, 2019 at 02:18:01PM +0200, Roberto Sassu wrote:
> From: Mimi Zohar <zohar@...ux.vnet.ibm.com>
> 
> This patch adds metadata to a file from a supplied buffer. The buffer might
> contains multiple metadata records. The format of each record is:
> 
> <metadata len (ASCII, 8 chars)><version><type><metadata>
> 
> For now, only the TYPE_XATTR metadata type is supported. The specific
> format of this metadata type is:
> 
> <xattr #N name>\0<xattr #N value>
> 
> [kamensky: fixed restoring of xattrs for symbolic links by using
>            sys_lsetxattr() instead of sys_setxattr()]
> 
> [sassu: removed state management, kept only do_setxattrs(), added support
>         for generic file metadata, replaced sys_lsetxattr() with
>         vfs_setxattr(), added check for entry_size, added check for
>         hdr->c_size, replaced strlen() with strnlen(); moved do_setxattrs()
>         before do_name()]
> 
> Signed-off-by: Mimi Zohar <zohar@...ux.vnet.ibm.com>
> Signed-off-by: Victor Kamensky <kamensky@...co.com>
> Signed-off-by: Taras Kondratiuk <takondra@...co.com>
> Signed-off-by: Roberto Sassu <roberto.sassu@...wei.com>
> ---
>  include/linux/initramfs.h | 21 ++++++++++
>  init/initramfs.c          | 88 ++++++++++++++++++++++++++++++++++++++-
>  2 files changed, 107 insertions(+), 2 deletions(-)
>  create mode 100644 include/linux/initramfs.h

[..]

> +static int __init do_setxattrs(char *pathname, char *buf, size_t size)
> +{
> +	struct path path;
> +	char *xattr_name, *xattr_value;
> +	size_t xattr_name_size, xattr_value_size;
> +	int ret;
> +
> +	xattr_name = buf;
> +	xattr_name_size = strnlen(xattr_name, size);
> +	if (xattr_name_size == size) {
> +		error("malformed xattrs");
> +		return -EINVAL;
> +	}
> +

[..]

> +
> +		switch (hdr->c_type) {
> +		case TYPE_XATTR:
> +			do_setxattrs(pathname, buf + sizeof(*hdr),
> +				     entry_size - sizeof(*hdr));

Is it on purpose not to check the return value of do_setxattrs?

I think I would have more comfort and piece of mind if I knew
the return value is properly checked and acted upon. Otherwise,
why returning an int from within do_setxattrs() at all?

BR, Eugeniu