[Rpm-maint] [rpm-software-management/rpm] paths[with spaces and square brackets] cannot be listed in %files (#1749)

[Michal Domonkos]

As far as semantics, what we should aim for, I think, is that it's similar to a typical shell (like Bash): the entries in a `%files` section are *pathnames* to be matched against the buildroot tree and are subject to *expansion* using the conventional glob characters.  Similarly to a shell, it should be possible to *escape* these characters.

As far as the current implementation, the glob chars *are* supported, but the backslash escape char only works *partially*; it avoids the expansion of the pathname in `processBinaryFile()`, but it is then passed to the low-level system functions like `lstat(2)` (via `addFile()`) unchanged, i.e. with the escape chars still in place, which obviously fails to match the desired filename.  In addition, the backslash doesn't work with spaces; there's a check that runs before pathname expansion that checks whether the given pathname is absolute; this check doesn't understand escaping, though, so it errors out, as seen in the original comment above.

As an alternative to the backslash, pathnames can be enclosed in quotes.  These *do* work for space chars, however, for a change, they do *not* work for glob chars.

As an example, for the following pathnames in `%files`, rpmbuild behaves as expected, similarly to a shell:

* `/foo[bar]` is expanded and if it doesn't yield any matches, it's matched
  verbatim
* `/foo bar` is interpreted as two paths
* `"/foo bar"` is matched verbatim

However, the following works unlike a shell and thus is arguably incorrect (or at least unconventional):

* `"/foo[bar]"` is expanded
* `/foo\ bar` is interpreted as two paths
* `/foo\[bar\]` is matched verbatim (i.e. with literal backslashes), whereas
  the expected semantics here would be "this is not a glob, treat is as a
  literal `/foo[bar]`")

Therefore, a combination of glob *and* space chars can't be properly escaped; neither backslashes nor quotes will do the trick here:

* `"/foo[bar baz]"` is expanded
* `/foo\[bar\ baz\]` is interpreted as two paths
* `"/foo\[bar baz\]"` is matched verbatim (i.e. with literal backslashes)

In other words, the root cause is threefold (same order as above):

* Quotes don't escape globs (just spaces)
* Backslashes don't escape spaces (just globs)
* Backslashes are not stripped after determining whether the pathname is a glob

Either the first or the last one, if addressed, would resolve this issue.  The second one is orthogonal to this particular problem, but would also be nice to have eventually.

Next, I'm going to look closer at the code and the logic around this to see if implementing some of the suggested fixes would be safe and not cause some breakage elsewhere.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1749#issuecomment-1020420616
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/issues/1749/1020420616 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20220124/5c5d046f/attachment.html>