Re: [RFC PATCH] initramfs: correctly handle space in path on cpio list generation

[David Disseldorp <ddiss@suse.de>]

On Tue, 10 Feb 2026 18:37:44 +0100, Christian Marangi wrote:
...
> > > diff --git a/usr/gen_init_cpio.c b/usr/gen_init_cpio.c
> > > index b7296edc6626..ca5950998841 100644
> > > --- a/usr/gen_init_cpio.c
> > > +++ b/usr/gen_init_cpio.c
> > > @@ -166,7 +166,7 @@ static int cpio_mkslink_line(const char *line)
> > >  	int gid;
> > >  	int rc = -1;
> > >  
> > > -	if (5 != sscanf(line, "%" str(PATH_MAX) "s %" str(PATH_MAX) "s %o %d %d", name, target, &mode, &uid, &gid)) {
> > > +	if (5 != sscanf(line, "\"%" str(PATH_MAX) "[^\"]\" \"%" str(PATH_MAX) "[^\"]\" %o %d %d", name, target, &mode, &uid, &gid)) {  
> > 
> > This breaks parsing of existing manifest files, so is unacceptable
> > IMO. If we really want to go down the route of having gen_init_cpio
> > support space-separated paths, then perhaps a new --field-separator
> > parameter might make sense. For your specific workload it seems that
> > simply using an external cpio archiver with space support (e.g. GNU
> > cpio --null) would make sense. Did you consider going down that
> > path?
> >   
> 
> This is mostly why this is posted as RFC. I honestly wants to fix this in the
> linux tool instead of using external tools.
> 
> So is there an actual use of manually passing the cpio list instead of
> generating one with the script? (just asking not saying that there isn't one)

Absolutely. As a simple example, consider an unprivileged user wishing
to add a device node to their initramfs image. A manifest entry (as
opposed to staging area mknod=EPERM) is ideal for this.

> One case I have (the scenario here is OpenWrt) is when a base cpio_list is
> provided and then stuff is appended to it.
> 
> In such case yes there is a problem since the format changed.
> 
> My solution to this would be introduce new type that will have the new pattern.
> This way we can keep support for the old list and still handle whitespace files.
> 
> An idea might be to have the file type with capital letter to differenciate with
> the old one.
> 
> Something like 
> 
> FILE "path" "location" ...
> SLINK "name" "target" ...
> NODE ...
> 
> What do you think?

Introducing a new type to handle space-containing filenames isn't a bad
idea, but using capital letters to signify the API change is confusing.

> The option of --field-separator might also work but it might complicate stuff in
> the .c tool as a more ""manual"" tokenizer will be needed than the simple
> implementation currently present.

What happens when someone wants support for filenames containing spaces
and quotes?

> I'm open to both solution. Lets just agree on one of the 2.

I don't think any of the options will be particularly simple, but
nul-byte delimited field support might be the most straightforward.

Thanks, David