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_2_Volume_2_1986.pdf 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