Summary: | app-cdr/cdrtools-3.01_alpha17 - checking bits in minor device number... configure: error: can not run test program while cross compiling | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Norman Shulman <norman.shulman> |
Component: | Current packages | Assignee: | Daniel Pielmeier <billie> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | media-optical, vapier |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
app-cdr/cdrtools-3.01_alpha17 build log
/var/tmp/portage/app-cdr/cdrtools-3.01_alpha17/work/cdrtools-3.01//incs/amd64-linux-cc/config.log |
Description
Norman Shulman
2013-10-01 16:24:51 UTC
Please attach the entire build log to this bug report. Created attachment 359982 [details]
app-cdr/cdrtools-3.01_alpha17 build log
configure believes to be in a cross compile environment when the simplest possible C program does not result in runnable core: main(){} This could be a result of a defective compiler installation. The fact that config.guess reports a permission problem leads to the assumption that the caller did set up a non working compile environment, e.g. by using a pathologigal umask value. Other packages emerge normally. Attach config.log that is generated by the ./configure from the /var/tmp/portage/app-cdr/cdrtools-3.01_alpha17/work/cdrtools-3.01 directory Created attachment 360328 [details]
/var/tmp/portage/app-cdr/cdrtools-3.01_alpha17/work/cdrtools-3.01//incs/amd64-linux-cc/config.log
from grsec.log: Oct 7 12:19:04 localhost kernel: [608348.353457] grsec: denied untrusted exec (due to file in group-writable directory) of /var/tmp/portage/app-cdr/cdrtools-3.01_alpha17/work/cdrtools-3.01/incs/amd64-linux-cc/conftest by /var/tmp/portage/app-cdr/cdrtools-3.01_alpha17/work/cdrtools-3.01/incs/amd64-linux-cc/conftest[sh:11260] uid/euid:250/250 gid/egid:250/250, parent /bin/bash[sh:11259] uid/euid:250/250 gid/egid:250/250 grsec & hardened related error, then (In reply to Samuli Suominen from comment #8) > grsec & hardened related error, then Hum, there is little we can do here except recommending the user to temporarily disable grsec's tpe restrict all feature. The issue is in portage itself, or whomever is leaving folders group writable in the build system. In particular the tmp folder is one such directory. As of now there is little that can be done other than recommending developers to place the programs to be run somewhere other than tmp. (In reply to Francisco Blas Izquierdo Riera from comment #9) > (In reply to Samuli Suominen from comment #8) > > grsec & hardened related error, then > > Hum, there is little we can do here except recommending the user to > temporarily disable grsec's tpe restrict all feature. > > The issue is in portage itself, or whomever is leaving folders group > writable in the build system. In particular the tmp folder is one such > directory. > > As of now there is little that can be done other than recommending > developers to place the programs to be run somewhere other than tmp. Add portage to the wheel group: gpasswd -a portage wheel and see if that helps portage is already in the wheel group: nshulman@nvshp:~ $ grep wheel /etc/group wheel:x:10:root,nshulman,portage It may be that the system in question is doing too much because it is not checking all security relevant constraints. A group writable directory is e.g. not a problem at all if there is only one person in that group or if the directory in question is below a directory that does not let others pass. On the other side, returning EACCESS is definitely a bug, as this is not the result of a native UNIX restriction caused by UNIX compliant interpretation of file permissions. Better would be to return something else - well Linux uses a missleading text for EPERM. Better would be the text "Not owner" as used on Solaris. In general, it seems that this system was written by people that did make their life easy instead of doing things right. In addition to the cases I already mentioned, there are other secure cases, that apply in our case: If an executable is only writable by the owner and if this is the same owner as the owner of the directory it is located in, there was no attack. The right way would be to check for real problems instead of trying to prevent execution of binaries that are at places that might be used for attacks but actually are not. You can always JUST disable TPE, you don't even have to recompile the kernel to do that if you enabled /proc configuration: echo 0 > /proc/sys/kernel/grsecurity/tpe_restrict_all And BTW, good luck trying to check who are the users in a group from kernel space as this is done from userspace. Also try to efficiently check all the directory chain permissions for a file. Now do it for every file you execute and enjoy the slowdown. As you see, you currently enjoy problems because there is something that makes its life easy, prevents execution of a secure binary. On the other side, a halfway clever implemented algorithm of course can do a much better check even from kernel space. Why not run dummy in the same place as all the other autoconfig test files? the gnuconfig files need updating so i've done that automatically: http://sources.gentoo.org/app-cdr/cdrtools/cdrtools-3.01_alpha21.ebuild?r1=1.1&r2=1.2 i added cross-compiler logic for caching vars: http://sources.gentoo.org/app-cdr/cdrtools/cdrtools-3.01_alpha21.ebuild?r1=1.2&r2=1.3 there are a lot of tests in this configure script that are run based when they don't need to be. let's ignore the minor_t checking for now. ac_cv_c_bitfields_htol can be checked simply by: cat <<-EOF >test.c struct { char start[6]; unsigned char x1:4; unsigned char x2:4; char end[5]; } a = { .start = {'S', 't', 'A', 'r', 'T', '_'}, .x1 = 5, .x2 = 4, .end = {'_', 'e', 'N', 'd', 'X'}, }; EOF gcc -c test.c -o test.o if grep -q 'StArT_E_eNdX' test.o ; then ac_cv_c_bitfields_htol="no" elif grep -q 'StArT_T_eNdX' test.o ; then ac_cv_c_bitfields_htol="yes" fi all of the tests that do sizeof() can be calculated by compiling only. autoconf has done this for over a decade. it also supports calculating alignments of types. basically it does: ac_sizeof_func() { cat <<-EOF >test.c int main () { static int test_array [1 - 2 * !((sizeof(TYPE)) == LEN)]; test_array [0] = 0; return test_array [0]; } EOF i=1 while [ $i -lt 60 ]; do if gcc -c test.c -DTYPE="$1" -DLEN=$i 2>/dev/null; then echo $i return 0 fi : $(( i += 1 )) done return 1 } ac_cv_sizeof_char=$(ac_sizeof_func "char") ac_cv_sizeof_int=$(ac_sizeof_func "int") ac_cv_sizeof_unsigned_short=$(ac_sizeof_func "unsigned short") in reality the code uses a binary search to speed things up, but you get the basic idea of how it works. for cases where you know the answer the majority of the time, you should just add a fallback. like for the mlock/mlockall cases, check $host_os and set it to no if it's hpux, else set it to yes. for cases where the code has builtin fallbacks, just use them. so for ecvt/fcvt/gcvt/dtoa_r, default to "no" when cross-compiling. the code base already has code that should work fine. there seems like there's some dead tests in here too -- cases where the computed define isn't actually used in the code base. like HAVE_SYS_SIGLIST, HAVE_SYS_SIGLIST_DEF, HAVE_PRINTF_J, HAVE_PRINTF_LL, HAVE_REALLOC_NULL, NO_USER_MALLOC, HAVE_VAR_TIMEZONE, HAVE_HARD_SYMLINKS, HAVE_LINK_NOFOLLOW, . if, for some weird reason, you want to keep all these things, then you could at least mitigate it by setting the cache vars at the top of the configure script or elsewhere in the build system. (In reply to SpanKY from comment #16) > the gnuconfig files need updating so i've done that automatically: > http://sources.gentoo.org/app-cdr/cdrtools/cdrtools-3.01_alpha21.ebuild?r1=1. > 1&r2=1.2 Why did you make the change to the removal of the profiled make files? The new command does not delete anything. So if anything is wrong with deleting the files the command could be removed completely. (In reply to Daniel Pielmeier from comment #17) i don't know what you're talking about. what are "profiled make files" ? (In reply to SpanKY from comment #18) > (In reply to Daniel Pielmeier from comment #17) > > i don't know what you're talking about. what are "profiled make files" ? Actually I don't know either. However in commit http://sources.gentoo.org/app-cdr/cdrtools/cdrtools-3.01_alpha21.ebuild?r1=1.1&r2=1.2 you made the following change: - rm -f $(find ./ -name '*_p.mk') || die "rm profiled" + rm -f *_p.mk || die "rm profiled" This makes the rm command remove nothing at all as none of these files are in the base directory. The removal of these "*_p.mk" files was added about more than five years ago by Peter Alfredsen (loki_val) in commit: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-cdr/cdrtools/cdrtools-2.01.01_alpha50.ebuild?hideattic=0&revision=1.1&view=markup Later he added a comment to this line stating "#Remove profiled make files" As I did not know if these files do any good or bad I left this command in the ebuild. (In reply to Daniel Pielmeier from comment #19) thanks, i misread that line. should be fixed now: http://sources.gentoo.org/app-cdr/cdrtools/cdrtools-3.01_alpha17.ebuild?r1=1.14&r2=1.15 http://sources.gentoo.org/app-cdr/cdrtools/cdrtools-3.01_alpha21.ebuild?r1=1.5&r2=1.6 http://sources.gentoo.org/app-cdr/cdrtools/cdrtools-3.01_alpha22.ebuild?r1=1.1&r2=1.2 (In reply to Francisco Blas Izquierdo Riera from comment #13) > You can always JUST disable TPE, you don't even have to recompile the kernel > to do that if you enabled /proc configuration: > echo 0 > /proc/sys/kernel/grsecurity/tpe_restrict_all I just had to use this workaround to be able to install catalyst in our new releng build box for amd64/x86. I have fixed this properly in alpha17+alpha24 because it was holding up some infra work. Specifically, I changed DEFUMASK in the build system, so that it didn't make group-writable directories (which trip grsec TPE). |