testsuite fix: timezone: failing due to permissions in cross testing
PATCH 1/1 testsuite fix: timezone: failing due to permissions in cross testing
timezone test driver "zic" creates testdata directory wuth umask 755, so only root owner/group has write permissions. However the buildroot system created has sshd as default user, so sh fails to write to test results in this folder. Work around by relaxing umask to 777
| /bin/sh: build/glibc-fa3b6cd5bdbc/build/timezone/testdata/America/New_York.test-result: Permission denied | Makefile:96: recipe for target 'build/glibc-fa3b6cd5bdbc/build/timezone/testdata/America/New_York' failed | make[2]: *** [build/glibc-fa3b6cd5bdbc/build/timezone/testdata/America/New_York] Error 1 | make[2]: Leaving directory 'build/glibc-fa3b6cd5bdbc/timezone' | Makefile:258: recipe for target 'timezone/xtests' failed
--- timezone/zic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
timezone/zic.c +1 -1
@@ -39,7 +39,7 @@ typedef int_fast64_t zic_t;#include <sys/stat.h> #endif #ifdef S_IRUSR -#define MKDIR_UMASK (S_IRUSR|S_IWUSR|S_IXUSR|S_IRGRP|S_IXGRP|S_IROTH|S_IXOTH) +#define MKDIR_UMASK (S_IRUSR|S_IWUSR|S_IXUSR|S_IRGRP|S_IWGRP|S_IXGRP|S_IROTH|S_IWOTH|S_IXOTH)#else #define MKDIR_UMASK 0755#endif
Signature · 1 line
2.7.4
PATCH 1/1 testsuite fix: timezone: failing due to permissions in cross testing
timezone/zic.c typedef int_fast64_t zic_t; · line 45
Quoted 7 lines
#ifdef S_IRUSRtimezone/zic.c +1
-1-#define MKDIR_UMASK (S_IRUSR|S_IWUSR|S_IXUSR|S_IRGRP|S_IXGRP|S_IROTH|S_IXOTH) +#define MKDIR_UMASK (S_IRUSR|S_IWUSR|S_IXUSR|S_IRGRP|S_IWGRP|S_IXGRP|S_IROTH|S_IWOTH|S_IXOTH)#else #define MKDIR_UMASK 0755#endif
The zic.c code is taken from upstream, and I'm loath to change it everywhere simply because a glibc test driver isn't working somewhere, as I expect this would lead to security holes elsewhere. Intead, how about changing the test script to chmod the testdata directory after zic creates it, or to segregate the tzdata directory from the other test results?
PATCH 1/1 testsuite fix: timezone: failing due to permissions in cross testing
Quoted 14 lines · Paul Eggert
Quoted 8 lines
? #ifdef
S_IRUSR(quoted diff) +1
-1-#define MKDIR_UMASK (S_IRUSR|S_IWUSR|S_IXUSR|S_IRGRP|S_IXGRP|S_IROTH|S_IXOTH) +#define MKDIR_UMASK(S_IRUSR|S_IWUSR|S_IXUSR|S_IRGRP|S_IWGRP|S_IXGRP|S_IROTH|S_IWOTH|S_IXOTH) ? #else
? #defineMKDIR_UMASK0755
? #endifThe
zic.ccode is taken from upstream, and I'm loath to change it everywhere simply because a glibc test driver isn't working somewhere, as I expect this would lead to security holes elsewhere. Intead, how about changing the test script to chmod the testdata directory after zic creates it, or to segregate the tzdata directory from the other test results?
OK, the idea here was to solicit ideas about how to go about addressing this. I need to dig into the test harness to see how it can be addressed in the way you suggest.
Thx,
-Vineet
PATCH 1/1 testsuite fix: timezone: failing due to permissions in cross testing
In reply to Vineet GuptaQuoted 2 lines · Vineet Gupta
timezone test driver "zic" creates testdata directory wuth umask 755, so only root owner/group has write permissions. However the buildroot
root should not be involved in running tests at all; all tests should run as a normal user, the same one that owns the build directory, and thus all files and directories in the build directory should be owned by that user. (Some tests use user namespaces to test functionality that requires root, but that's root inside a namespace, not the real user root.)
So I think you need to explain more about your test configuration that results in permissions problems so we can tell if you have a valid test configuration at all.
Signature · 2 lines
Joseph S. Myers joseph at codesourcery.com
PATCH 1/1 testsuite fix: timezone: failing due to permissions in cross testing
Quoted 10 lines · Joseph Myers
Quoted 2 lines · Vineet Gupta
timezone test driver "zic" creates testdata directory wuth umask 755, so only root owner/group has write permissions. However the buildroot
root should not be involved in running tests at all; all tests should run as a normal user, the same one that owns the build directory, and thus all files and directories in the build directory should be owned by that user. (Some tests use user namespaces to test functionality that requires root, but that's root inside a namespace, not the real user root.)
Quoted 3 lines
So I think you need to explain more about your test configuration that results in permissions problems so we can tell if you have a valid test configuration at all.
The setup is obviously is cross test, built using buildroot. The system is minimal with root allowed w/o password to enable tests to run quickly.
On host I do the following which certainly involves root.
| make test-wrapper='<path-to-build-folder>/scripts/cross-test-ssh.sh root at 192.168.0.20' xcheck
So guess it needs to be sshd or some other user on target ?
PATCH 1/1 testsuite fix: timezone: failing due to permissions in cross testing
Quoted 9 lines · Vineet Gupta
The setup is obviously is cross test, built using buildroot. The system is minimal with root allowed w/o password to enable tests to run quickly.
On host I do the following which certainly involves root.
| make test-wrapper='<path-to-build-folder>/scripts/cross-test-ssh.sh root at 192.168.0.20' xcheck
So guess it needs to be sshd or some other user on target ?
The user on target should be the same as the user on the system where you build glibc (you may need to create a corresponding user on the target).
Signature · 2 lines
Joseph S. Myers joseph at codesourcery.com
PATCH 1/1 testsuite fix: timezone: failing due to permissions in cross testing
In reply to Joseph Myers* Joseph Myers:
Quoted 10 lines · Vineet Gupta
Quoted 3 lines
timezone test driver "zic" creates testdata directory wuth umask 755, so only root owner/group has write permissions. However the buildroot
root should not be involved in running tests at all; all tests should run as a normal user, the same one that owns the build directory, and thus all files and directories in the build directory should be owned by that user. (Some tests use user namespaces to test functionality that requires root, but that's root inside a namespace, not the real user root.)
There are also some xtests that require root privileges, such as nptl/tst-setuid1. Building and testing as root is supported (but obviously not recommended unless you use a throwaway machine).
Thanks,
Florian
PATCH 1/1 testsuite fix: timezone: failing due to permissions in cross testing
Quoted 2 lines · Florian Weimer
There are also some xtests that require root privileges, such as nptl/tst-setuid1. Building and testing as root is supported (but
That looks like it ought to become a test using user namespaces (and so not an xtest).
Quoted 1 line
obviously not recommended unless you use a throwaway machine).
And the combination of some parts of the testsuite writing to the build directory as root and other parts as a normal user isn't supported, in particular.
Signature · 2 lines
Joseph S. Myers joseph at codesourcery.com
PATCH 1/1 testsuite fix: timezone: failing due to permissions in cross testing
* Joseph Myers:
Quoted 7 lines · Florian Weimer
Quoted 3 lines
There are also some xtests that require root privileges, such as nptl/tst-setuid1. Building and testing as root is supported (but
That looks like it ought to become a test using user namespaces (and so not an xtest).
Can an unprivileged user namespace really be used to get a working setuid? The setup code in support_become_root/setup_uid_gid_mapping does not provide that.
Thanks,
Florian
PATCH 1/1 testsuite fix: timezone: failing due to permissions in cross testing
In reply to Joseph MyersQuoted 5 lines · Joseph Myers
root should not be involved in running tests at all; all tests should run as a normal user, the same one that owns the build directory, and thus all files and directories in the build directory should be owned by that user. (Some tests use user namespaces to test functionality that requires root, but that's root inside a namespace, not the real user root.)
I agree with this, but it is really hard /cumbersome to do this in a cross setup, with a busybox based system. We need the real/full blown utilities and do this natively.