aarch64: test -r with bash issue
It took me some time, but somehow bash is not behaving as expected within a qemu-aarch64 chroot jail. If I do the following: if test -r <some file>; then echo ok; fi Then the reply is 'ok' under normal x86_64 TW. However, when I started a chroot jail using qemu-aarch64 the reply stays empty. Only when I execute if test *!* -r <some file>; then echo ok; fi the response is 'ok'. And <some file> is always the same. I start the jail with the next command: /usr/bin/qemu-aarch64 -strace -cpu cortex-a53 -L /newroot /newroot/usr/sbin/chroot "/newroot" \ /usr/bin/env -i \ HOME=/root \ TERM="$TERM" \ PS1='(lfs chroot) \u:\w\$ ' \ PS4='(${BASH_SOURCE}:${LINENO}: ${FUNCNAME[0]} - [${SHLVL},${BASH_SUBSHELL}, $?] ' \ PATH=/usr/bin:/usr/sbin \ /usr/bin/bash --login +h Also, I copied a static version of qemu-aarch64 /and/ qemu_binfmt into /newroot/usr/bin - I also tried my own compiled version of qemu-aarch64-static, with the same result. Programs run, but bash seems to have this specific issue with the -r test. Other flags I tested -f, -s, -x etc. are working correctly. The -r flags is the only flag which - I presume - really does a reading test, while others test availability and some file flags. Maybe binfmt is to blame?? It is blocking me from compiling programs under aarch64 because the configure script is using these tests. If I change the ´-r´ flag within configure into a ´-s´, everything does work well. Regards, Frans.
On Thu, 2021-09-02 at 11:15 +0200, Frans de Boer wrote:
It took me some time, but somehow bash is not behaving as expected within a qemu-aarch64 chroot jail. If I do the following: if test -r <some file>; then echo ok; fi Then the reply is 'ok' under normal x86_64 TW. ... Also, I copied a static version of qemu-aarch64 and qemu_binfmt into /newroot/usr/bin - I also tried my own compiled version of qemu- aarch64-static, with the same result. Programs run, but bash seems to have this specific issue with the -r test. Other flags I tested -f, -s, -x etc. are working correctly. The -r flags is the only flag which - I presume - really does a reading test, while others test availability and some file flags. Maybe binfmt is to blame?? It is blocking me from compiling programs under aarch64 because the configure script is using these tests. If I change the ´-r´ flag within configure into a ´-s´, everything does work well.
Well, test -s and test -r are very different things. This means you have a permission problem. "test -r $file" basically runs "access($file, R_OK)". Check your permissions. Try running test under strace. Try disabling apparmor. Regards Martin
On Thursday 2021-09-02 11:27, Martin Wilck wrote:
On Thu, 2021-09-02 at 11:15 +0200, Frans de Boer wrote:
If I do the following: if test -r <some file>; then echo ok; fi Then the reply is 'ok' under normal x86_64 TW. [...]It is blocking me from compiling programs under aarch64 because the configure script is using these tests. If I change the ´-r´ flag within configure into a ´-s´, everything does work well.
Well, test -s and test -r are very different things.
Not only that. test and test are different! I had a debugging session on IRC not too long ago involving configure and test inside a docker namespace, with a surprising result: [root@46d397eef00e /]# cat /etc/redhat-release Fedora release 34 (Thirty Four) [root@46d397eef00e /]# /bin/test -x / ; echo $? 0 [root@46d397eef00e /]# test -x / ; echo $? 1 Tracing revealed that one is using faccessat(2), the other is using access(2), which pointed to syscall filtering being the culprit. Even though qemu does not filter, it may need to emulate/passthru, and that slope is sooo slippery.
On Thu, 02 Sep 2021, 11:15:00 +0200, Frans de Boer wrote:
It took me some time, but somehow bash is not behaving as expected within a qemu-aarch64 chroot jail.
If I do the following: if test -r <some file>; then echo ok; fi Then the reply is 'ok' under normal x86_64 TW.
Please show all details about <some file> within the chroot. The "-r" flag checks "FILE exists and read permission is granted".
However, when I started a chroot jail using qemu-aarch64 the reply stays empty. Only when I execute if test ! -r <some file>; then echo ok; fi the response is 'ok'. And <some file> is always the same.
I start the jail with the next command: /usr/bin/qemu-aarch64 -strace -cpu cortex-a53 -L /newroot /newroot/usr/sbin/ chroot "/newroot" \ /usr/bin/env -i \ HOME=/root \ TERM="$TERM" \ PS1='(lfs chroot) \u:\w\$ ' \ PS4='(${BASH_SOURCE}:${LINENO}: ${FUNCNAME[0]} - [${SHLVL},$ {BASH_SUBSHELL}, $?] ' \ PATH=/usr/bin:/usr/sbin \ /usr/bin/bash --login +h
Also, I copied a static version of qemu-aarch64 and qemu_binfmt into /newroot/ usr/bin - I also tried my own compiled version of qemu-aarch64-static, with the same result. Programs run, but bash seems to have this specific issue with the -r test. Other flags I tested -f, -s, -x etc. are working correctly.
These flags don't check the _read_ permission for the executing user.
The -r flags is the only flag which - I presume - really does a reading test, while others test availability and some file flags. Maybe binfmt is to blame??
It is blocking me from compiling programs under aarch64 because the configure script is using these tests. If I change the ´-r´ flag within configure into a ´-s´, everything does work well.
Regards, Frans.
HTH, cheers. l8er manfred
On Thu, 02 Sep 2021, 11:15:00 +0200, Frans de Boer wrote:
It took me some time, but somehow bash is not behaving as expected within a qemu-aarch64 chroot jail.
If I do the following: if test -r <some file>; then echo ok; fi Then the reply is 'ok' under normal x86_64 TW. Please show all details about <some file> within the chroot. The "-r" flag checks "FILE exists and read permission is granted". I used <some file> because you can pick /*ANY*/ file with their read
On 9/2/21 11:35, Manfred Hollstein wrote: permission set. Of course I checked that.
However, when I started a chroot jail using qemu-aarch64 the reply stays empty. Only when I execute if test ! -r <some file>; then echo ok; fi the response is 'ok'. And <some file> is always the same.
I start the jail with the next command: /usr/bin/qemu-aarch64 -strace -cpu cortex-a53 -L /newroot /newroot/usr/sbin/ chroot "/newroot" \ /usr/bin/env -i \ HOME=/root \ TERM="$TERM" \ PS1='(lfs chroot) \u:\w\$ ' \ PS4='(${BASH_SOURCE}:${LINENO}: ${FUNCNAME[0]} - [${SHLVL},$ {BASH_SUBSHELL}, $?] ' \ PATH=/usr/bin:/usr/sbin \ /usr/bin/bash --login +h
Also, I copied a static version of qemu-aarch64 and qemu_binfmt into /newroot/ usr/bin - I also tried my own compiled version of qemu-aarch64-static, with the same result. Programs run, but bash seems to have this specific issue with the -r test. Other flags I tested -f, -s, -x etc. are working correctly. These flags don't check the _read_ permission for the executing user. I never said that it would. And as a bonus, it is all at UID 0 level. The -r flags is the only flag which - I presume - really does a reading test, while others test availability and some file flags. Maybe binfmt is to blame??
It is blocking me from compiling programs under aarch64 because the configure script is using these tests. If I change the ´-r´ flag within configure into a ´-s´, everything does work well.
Regards, Frans. HTH, cheers.
l8er manfred --- Frans
On 9/3/21 22:02, Frans de Boer wrote:
On Thu, 02 Sep 2021, 11:15:00 +0200, Frans de Boer wrote:
It took me some time, but somehow bash is not behaving as expected within a qemu-aarch64 chroot jail.
If I do the following: if test -r <some file>; then echo ok; fi Then the reply is 'ok' under normal x86_64 TW. Please show all details about <some file> within the chroot. The "-r" flag checks "FILE exists and read permission is granted". I used <some file> because you can pick /*ANY*/ file with their read
On 9/2/21 11:35, Manfred Hollstein wrote: permission set. Of course I checked that.
However, when I started a chroot jail using qemu-aarch64 the reply stays empty. Only when I execute if test ! -r <some file>; then echo ok; fi the response is 'ok'. And <some file> is always the same.
I start the jail with the next command: /usr/bin/qemu-aarch64 -strace -cpu cortex-a53 -L /newroot /newroot/usr/sbin/ chroot "/newroot" \ /usr/bin/env -i \ HOME=/root \ TERM="$TERM" \ PS1='(lfs chroot) \u:\w\$ ' \ PS4='(${BASH_SOURCE}:${LINENO}: ${FUNCNAME[0]} - [${SHLVL},$ {BASH_SUBSHELL}, $?] ' \ PATH=/usr/bin:/usr/sbin \ /usr/bin/bash --login +h
Also, I copied a static version of qemu-aarch64 and qemu_binfmt into /newroot/ usr/bin - I also tried my own compiled version of qemu-aarch64-static, with the same result. Programs run, but bash seems to have this specific issue with the -r test. Other flags I tested -f, -s, -x etc. are working correctly. These flags don't check the _read_ permission for the executing user. I never said that it would. And as a bonus, it is all at UID 0 level. The -r flags is the only flag which - I presume - really does a reading test, while others test availability and some file flags. Maybe binfmt is to blame??
It is blocking me from compiling programs under aarch64 because the configure script is using these tests. If I change the ´-r´ flag within configure into a ´-s´, everything does work well.
Regards, Frans. HTH, cheers.
l8er manfred --- Frans Okay, after many more tests I still have problems with the -r and -x flags. Maybe some untested flags too. Just tested additional -a, -d, -e, -f, -s flags. They work. I found the -r and -x tests in configure and Makefiles and probably others too.
I trow the towel into the ring as far as building a new system image from scratch which differ from the building host and using qemu-xxxx and qemu-xxxx-binfmt. As far as I now understand, you need to have a running target system in order to build a new system image. Qemu can't help there. How does OpenSuse build images for systems other then x86_64? --- Frans.
On 9/3/21 22:14, Frans de Boer wrote:
On 9/3/21 22:02, Frans de Boer wrote:
On Thu, 02 Sep 2021, 11:15:00 +0200, Frans de Boer wrote:
It took me some time, but somehow bash is not behaving as expected within a qemu-aarch64 chroot jail.
If I do the following: if test -r <some file>; then echo ok; fi Then the reply is 'ok' under normal x86_64 TW. Please show all details about <some file> within the chroot. The "-r" flag checks "FILE exists and read permission is granted". I used <some file> because you can pick /*ANY*/ file with their read
On 9/2/21 11:35, Manfred Hollstein wrote: permission set. Of course I checked that.
However, when I started a chroot jail using qemu-aarch64 the reply stays empty. Only when I execute if test ! -r <some file>; then echo ok; fi the response is 'ok'. And <some file> is always the same.
I start the jail with the next command: /usr/bin/qemu-aarch64 -strace -cpu cortex-a53 -L /newroot /newroot/usr/sbin/ chroot "/newroot" \ /usr/bin/env -i \ HOME=/root \ TERM="$TERM" \ PS1='(lfs chroot) \u:\w\$ ' \ PS4='(${BASH_SOURCE}:${LINENO}: ${FUNCNAME[0]} - [${SHLVL},$ {BASH_SUBSHELL}, $?] ' \ PATH=/usr/bin:/usr/sbin \ /usr/bin/bash --login +h
Also, I copied a static version of qemu-aarch64 and qemu_binfmt into /newroot/ usr/bin - I also tried my own compiled version of qemu-aarch64-static, with the same result. Programs run, but bash seems to have this specific issue with the -r test. Other flags I tested -f, -s, -x etc. are working correctly. These flags don't check the _read_ permission for the executing user. I never said that it would. And as a bonus, it is all at UID 0 level. The -r flags is the only flag which - I presume - really does a reading test, while others test availability and some file flags. Maybe binfmt is to blame??
It is blocking me from compiling programs under aarch64 because the configure script is using these tests. If I change the ´-r´ flag within configure into a ´-s´, everything does work well.
Regards, Frans. HTH, cheers.
l8er manfred --- Frans Okay, after many more tests I still have problems with the -r and -x flags. Maybe some untested flags too. Just tested additional -a, -d, -e, -f, -s flags. They work. I found the -r and -x tests in configure and Makefiles and probably others too.
I trow the towel into the ring as far as building a new system image from scratch which differ from the building host and using qemu-xxxx and qemu-xxxx-binfmt. As far as I now understand, you need to have a running target system in order to build a new system image. Qemu can't help there.
How does OpenSuse build images for systems other then x86_64?
--- Frans. Tried the same with ppc64, same bad results.
Frans -- A: Yes, just like that A: Ja, net zo Q: Oh, Just like reading a book backwards Q: Oh, net als een boek achterstevoren lezen A: Because it upsets the natural flow of a story A: Omdat het de natuurlijke gang uit het verhaal haalt Q: Why is top-posting annoying? Q: Waarom is Top-posting zo irritant?
Hi, openSUSE builds natively for aarch64, armv6/7, etc. inside a qemu KVM. Also, you can build inside a full qemu (non-KVM, so slowly). Guillaume From: Frans de Boer <frans@fransdb.nl> Sent: 03 September 2021 22:14 To: factory@lists.opensuse.org Subject: Re: aarch64: test -r with bash issue On 9/3/21 22:02, Frans de Boer wrote: On 9/2/21 11:35, Manfred Hollstein wrote: On Thu, 02 Sep 2021, 11:15:00 +0200, Frans de Boer wrote: It took me some time, but somehow bash is not behaving as expected within a qemu-aarch64 chroot jail. If I do the following: if test -r <some file>; then echo ok; fi Then the reply is 'ok' under normal x86_64 TW. Please show all details about <some file> within the chroot. The "-r" flag checks "FILE exists and read permission is granted". I used <some file> because you can pick ANY file with their read permission set. Of course I checked that. However, when I started a chroot jail using qemu-aarch64 the reply stays empty. Only when I execute if test ! -r <some file>; then echo ok; fi the response is 'ok'. And <some file> is always the same. I start the jail with the next command: /usr/bin/qemu-aarch64 -strace -cpu cortex-a53 -L /newroot /newroot/usr/sbin/ chroot "/newroot" \ /usr/bin/env -i \ HOME=/root \ TERM="$TERM" \ PS1='(lfs chroot) \u:\w\$ ' \ PS4='(${BASH_SOURCE}:${LINENO}: ${FUNCNAME[0]} - [${SHLVL},$ {BASH_SUBSHELL}, $?] ' \ PATH=/usr/bin:/usr/sbin \ /usr/bin/bash --login +h Also, I copied a static version of qemu-aarch64 and qemu_binfmt into /newroot/ usr/bin - I also tried my own compiled version of qemu-aarch64-static, with the same result. Programs run, but bash seems to have this specific issue with the -r test. Other flags I tested -f, -s, -x etc. are working correctly. These flags don't check the _read_ permission for the executing user. I never said that it would. And as a bonus, it is all at UID 0 level. The -r flags is the only flag which - I presume - really does a reading test, while others test availability and some file flags. Maybe binfmt is to blame?? It is blocking me from compiling programs under aarch64 because the configure script is using these tests. If I change the ´-r´ flag within configure into a ´-s´, everything does work well. Regards, Frans. HTH, cheers. l8er manfred --- Frans Okay, after many more tests I still have problems with the -r and -x flags. Maybe some untested flags too. Just tested additional -a, -d, -e, -f, -s flags. They work. I found the -r and -x tests in configure and Makefiles and probably others too. I trow the towel into the ring as far as building a new system image from scratch which differ from the building host and using qemu-xxxx and qemu-xxxx-binfmt. As far as I now understand, you need to have a running target system in order to build a new system image. Qemu can't help there. How does OpenSuse build images for systems other then x86_64? --- Frans.
Continue top-posting...( See remarks below. Frans. On 9/6/21 10:20, Guillaume Gardet wrote:
Hi, openSUSE builds natively for aarch64, armv6/7, etc. inside a qemu KVM. That implies that you already have a bootable environment for arm etc.? Also, you can build inside a full qemu (non-KVM, so slowly). Using qemu without KVM is slow indeed. However, to my knowledge, here you need a bootable environment also?
Guillaume *From:* Frans de Boer <frans@fransdb.nl> *Sent:* 03 September 2021 22:14 *To:* factory@lists.opensuse.org *Subject:* Re: aarch64: test -r with bash issue On 9/3/21 22:02, Frans de Boer wrote: On 9/2/21 11:35, Manfred Hollstein wrote: On Thu, 02 Sep 2021, 11:15:00 +0200, Frans de Boer wrote: It took me some time, but somehow bash is not behaving as expected within a qemu-aarch64 chroot jail. If I do the following: if test -r <some file>; then echo ok; fi Then the reply is 'ok' under normal x86_64 TW. Please show all details about <some file> within the chroot. The "-r" flag checks "FILE exists and read permission is granted". I used <some file> because you can pick */ANY/* file with their read permission set. Of course I checked that. However, when I started a chroot jail using qemu-aarch64 the reply stays empty. Only when I execute if test ! -r <some file>; then echo ok; fi the response is 'ok'. And <some file> is always the same. I start the jail with the next command: /usr/bin/qemu-aarch64 -strace -cpu cortex-a53 -L /newroot /newroot/usr/sbin/ chroot "/newroot" \ /usr/bin/env -i \ HOME=/root \ TERM="$TERM" \ PS1='(lfs chroot) \u:\w\$ ' \ PS4='(${BASH_SOURCE}:${LINENO}: ${FUNCNAME[0]} - [${SHLVL},$ {BASH_SUBSHELL}, $?] ' \ PATH=/usr/bin:/usr/sbin \ /usr/bin/bash --login +h Also, I copied a static version of qemu-aarch64 and qemu_binfmt into /newroot/ usr/bin - I also tried my own compiled version of qemu-aarch64-static, with the same result. Programs run, but bash seems to have this specific issue with the -r test. Other flags I tested -f, -s, -x etc. are working correctly. These flags don't check the _read_ permission for the executing user. I never said that it would. And as a bonus, it is all at UID 0 level. The -r flags is the only flag which - I presume - really does a reading test, while others test availability and some file flags. Maybe binfmt is to blame?? It is blocking me from compiling programs under aarch64 because the configure script is using these tests. If I change the ´-r´ flag within configure into a ´-s´, everything does work well. Regards, Frans. HTH, cheers. l8er manfred --- Frans Okay, after many more tests I still have problems with the -r and -x flags. Maybe some untested flags too. Just tested additional -a, -d, -e, -f, -s flags. They work. I found the -r and -x tests in configure and Makefiles and probably others too.
I trow the towel into the ring as far as building a new system image from scratch which differ from the building host and using qemu-xxxx and qemu-xxxx-binfmt. As far as I now understand, you need to have a running target system in order to build a new system image. Qemu can't help there.
How does OpenSuse build images for systems other then x86_64?
--- Frans.
-- A: Yes, just like that A: Ja, net zo Q: Oh, Just like reading a book backwards Q: Oh, net als een boek achterstevoren lezen A: Because it upsets the natural flow of a story A: Omdat het de natuurlijke gang uit het verhaal haalt Q: Why is top-posting annoying? Q: Waarom is Top-posting zo irritant?
participants (5)
-
Frans de Boer -
Guillaume Gardet -
Jan Engelhardt -
Manfred Hollstein -
Martin Wilck