Re: [PATCH] seccomp.sh: Quote tr character ranges to prevent glob expansion

On Fri, Nov 14, 2025 at 01:01:03AM +0100, Stefano Brivio wrote:

On Wed, 5 Nov 2025 12:22:38 +1100 David Gibson wrote:

...

On Tue, Nov 04, 2025 at 06:01:49AM +0100, Stefano Brivio wrote:

...

On Mon, 3 Nov 2025 13:08:34 +0100 Laurent Vivier wrote:

...

we use [a-z] and [A-Z] patterns with 'tr', but if there are files with names matching these patterns they will be replaced by the name of the file and seccomp.h will not be generated correctly: $ rm seccomp.h $ touch a b $ make tr: extra operand '[A-Z]' Try 'tr --help' for more information. seccomp profile passt allows: accept accept4 bind clock_gettime close connect epoll_ctl epoll_pwait epoll_wait exit_group fallocate fcntl fsync ftruncate getsockname getsockopt listen lseek read recvfrom recvmmsg recvmsg sendmmsg sendmsg sendto ... cc -Wall -Wextra -Wno-format-zero-length -Wformat-security -pedantic -std=c11 -D_XOPEN_SOURCE=700 -D_GNU_SOURCE -D_FORTIFY_SOURCE=2 -O2 -pie -fPIE -DPAGE_SIZE=4096 -DVERSION="2025_09_19.623dbf6-54-gf6b6118fcabd" -DDUAL_STACK_SOCKETS=1 -DHAS_GETRANDOM -fstack-protector-strong arch.c arp.c checksum.c conf.c dhcp.c dhcpv6.c epoll_ctl.c flow.c fwd.c icmp.c igmp.c inany.c iov.c ip.c isolation.c lineread.c log.c mld.c ndp.c netlink.c migrate.c packet.c passt.c pasta.c pcap.c pif.c repair.c tap.c tcp.c tcp_buf.c tcp_splice.c tcp_vu.c udp.c udp_flow.c udp_vu.c util.c vhost_user.c virtio.c vu_common.c -o passt In file included from isolation.c:83: seccomp.h:11:45: error: 'AUDIT_ARCH_' undeclared here (not in a function); did you mean 'AUDIT_ARCH'? 11 | BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, AUDIT_ARCH_, 0, 80), | ^~~~~~~~~~~

Signed-off-by: Laurent Vivier --- seccomp.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/seccomp.sh b/seccomp.sh index a7bc417b9f6b..ba92b29d9a29 100755 --- a/seccomp.sh +++ b/seccomp.sh @@ -22,7 +22,7 @@ IN="$@" [ -z "${ARCH}" ] && ARCH="$(uname -m)" [ -z "${CC}" ] && CC="cc"

-AUDIT_ARCH="AUDIT_ARCH_$(echo ${ARCH} | tr [a-z] [A-Z] \ +AUDIT_ARCH="AUDIT_ARCH_$(echo ${ARCH} | tr '[a-z]' '[A-Z]' \

Oops.

I wonder if this is a complete fix though, because in general I didn't care about possible expansions and I just assumed I set -f on the whole script, which I didn't for some reason. That is, it should be:

#!/bin/sh -euf

and if you run 'shellcheck seccomp.sh', you'll find many other places where I didn't care, so perhaps we really need that -f, but I didn't look into all those shellcheck reports.

And by the way of shellcheck and compatibility, this is still on my to-do list:

https://github.com/chimera-linux/cports/pull/1483#issuecomment-2079007408

All in all, I can apply this, it fixes a bit and surely doesn't hurt.

Or we can (also?) add -f, but we need to make sure we don't rely on expansions. We should perhaps check / fix reasonable shellcheck reports and compatibility issues too.

I don't love that idea. I hadn't even realised -f existed until right now, so having an obscure global flag change behaviour everywhere doesn't ideal for readability.

I don't think it's *that* obscure actually, I use it quite commonly (unless the script is playing with files), I have a few occurrences of it in my current /usr/lib, and it even predates POSIX and SUS.

...

From page 108 of AT&T's System V Interface Definition, Issue 2 Volume II, Chapter 4 (Commands and Utilities), SH(BU_CMD):

-f (New in System V Release 2.) Disable file name generation

https://bitsavers.org/pdf/att/unix/SVID/System_V_Interface_Definition_Issue_...

Being ancient doesn't, of itself, make it less obscure... Empirically, I've been using shell on and off for 30 years, and I'd never encountered it.

...

Plus, disabling globs removes the need for _some_ escaping, but not all, so it just means there's now two different sets of rules you'd need to apply about what must be escaped.

Well, I think we should escape everything anyway, and make sure we do by making it shellcheck(1)-clean, eventually.

But '[a-z]' in 'tr [a-z]' expanding to 'a' is the very madness that -f is supposed to protect us from. That is, I see it as something needed for defensive/robust programming rather than something hiding issues.

Eh, I suppose. I mean the main lesson I see is "trying to get anything complex right in shell is a fool's errand"... -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson