linux-ext4 - Re: [PATCH 1/1] mke2fs: the -d option can now handle tarball input

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-next>] [day] [month] [year] [list]

Date:   Tue, 11 Jul 2023 16:53:54 -0700
From:   "Darrick J. Wong" <djwong@...nel.org>
To:     Johannes Schauer Marin Rodrigues <josch@...ter-muffin.de>
Cc:     linux-ext4@...r.kernel.org
Subject: Re: [PATCH 1/1] mke2fs: the -d option can now handle tarball input

On Mon, Jul 03, 2023 at 07:43:56AM +0200, Johannes Schauer Marin Rodrigues wrote:
> Hi,
> 
> Quoting Darrick J. Wong (2023-06-30 17:51:28)
> > On Tue, Jun 20, 2023 at 02:16:41PM +0200, Johannes Schauer Marin Rodrigues wrote:
> > > If archive.h is available during compilation, enable mke2fs to read a
> > > tarball as input. Since libarchive.so.13 is opened with dlopen,
> > > libarchive is not a hard library dependency of the resulting binary.
> > 
> > I can't say I'm in favor of adding build dependencies to e2fsprogs,
> > since the point of -d taking a directory arg was to *avoid* having to
> > understand anything other than posix(ish) directory tree walking APIs.
> 
> this is why the build dependency is optional.

As Ted said elsewhere, the big question is (a) do we really want
e2fsprogs depending on libarchive at all, and (b) is libarchive's API
stable enough that you'll maintain it for us?  Merging this patch *is*
adding to the complexity of what most distros consider to be critical
system utility.

> It should be perfectly possible
> to build e2fsprogs without libarchive as well. I copied the pattern that was
> already implemented for libmagic which is also not a hard dependency but gets
> dlopened-ed at runtime. If this mechanism is fine for libmagic it should be
> fine for others as well, no?
> 
> The tar format (minus some features) is also not terribly complicated. Would

There's at least five formats known to GNU tar, according to its manpage:

Format	UID		File Size	File Name	Devn
gnu	1.8e19		Unlimited	Unlimited	63
oldgnu	1.8e19		Unlimited	Unlimited	63
v7	2097151		8GB		99		n/a
ustar	2097151		8GB		256		21
posix	Unlimited	Unlimited	Unlimited	Unlimited

https://www.gnu.org/software/tar/manual/html_chapter/Formats.html

> you prefer I add a rudimentary tar parser that will be used in the event that
> libarchive is not available? The tar format is not that complicated but adding
> such code to e2fsprogs would be overkill for a functionality that is otherwise
> optional, no?

Indeed not.

> > > This enables the creation of filesystems containing files which would
> > > otherwise need superuser privileges to create (like device nodes, which are
> > > also not allowed in unshared user namespaces). By reading from standard
> > > input when the filename is a dash (-), mke2fs can be used as part of a
> > > shell pipeline without temporary files.
> > What if the argument is actually a Microsoft CAB archive (which libarchive
> > claims to support)?  Will it actually copy the cab archive into an ext4
> > image?
> 
> I didn't have a cab archive so I couldn't test this but it does work with other
> archive formats like zip files. Would you like me to artificially restrict the
> input format to only tarballs?

No -- if Ted wants libarchive input for e2fsprogs, it may as well take
full advantage of it.

--D

> Thanks!
> 
> cheers, josch