bug#35650: [PATCH] Improving HP-UX support
Am 2019-05-14 um 18:26 schrieb Paul Eggert: On 5/14/19 6:52 AM, Osipov, Michael wrote: aCC does not exit with non-zero, it just prints a warning. OK, I installed the attached patch to try to fix this problem with 'configure'. Please give it a try. We may need some more patches to fix the problems you evidently observed with #include_next, getacl, aclsort, and sys/bitypes.h. So: checking whether C compiler handles -Werror... no checking whether C compiler handles -errwarn... no checking whether this system supports stdbuf... yes in detail: configure:68484: checking whether C compiler handles -Werror configure:68503: /opt/aCC/bin/aCC -AC99 -o conftest -g -Werror -I/opt/ports/coreutils/include -D_INCLUDE_STDC__SOURCE_199901 -L/opt/ports/coreutils/lib/hpux32 conftest.c >&5 aCC: error 1914: bad form for `-W' option configure:68503: $? = 1 > configure:68513: result: no> configure:68522: checking whether C compiler handles -errwarn configure:68541: /opt/aCC/bin/aCC -AC99 -o conftest -g -errwarn -I/opt/ports/coreutils/include -D_INCLUDE_STDC__SOURCE_199901 -L/opt/ports/coreutils/lib/hpux32 conftest.c >&5 ld: Entry symbol "rrwarn" not found Fatal error. configure:68541: $? = 1 configure:68551: result: no configure:68559: checking whether this system supports stdbuf configure:68586: /opt/aCC/bin/aCC -AC99 -o conftest +z -g -I/opt/ports/coreutils/include -D_INCLUDE_STDC__SOURCE_199901 -b -L/opt/ports/coreutils/lib/hpux32 conftest.c >&5 configure:68586: $? = 0 configure:68591: result: yes I do not really understand the purpose of the patch as it does not really test for PIC/shared. This [1] is a viable approach I have taken to make it work for linker style on HP-UX. I guess one could steal that and reuse for -fPIC/+z. [1] https://github.com/git/git/pull/608/files WDYT? Michael
bug#35650: [PATCH] Improving HP-UX support
On 5/14/19 6:52 AM, Osipov, Michael wrote: > > aCC does not exit with non-zero, it just prints a warning. OK, I installed the attached patch to try to fix this problem with 'configure'. Please give it a try. We may need some more patches to fix the problems you evidently observed with #include_next, getacl, aclsort, and sys/bitypes.h. >From 9eb544252ca9ecb9b52b8a26bd98a5e6723bbc3a Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 14 May 2019 09:20:56 -0700 Subject: [PATCH] stdbuf: port configure-time checking to HP-UX aCC Problem reported by Michael Osipov (Bug#35650). * configure.ac: Use AC_LANG_WERROR to pay attention to compiler and linker warnings when testing whether stdbuf will work. --- configure.ac | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configure.ac b/configure.ac index 0ee01b2cd..f97ff862e 100644 --- a/configure.ac +++ b/configure.ac @@ -476,6 +476,8 @@ fi # Build stdbuf only if supported ac_save_CFLAGS=$CFLAGS ac_save_LDFLAGS=$LDFLAGS +cu_save_c_werror_flag=$ac_c_werror_flag +AC_LANG_WERROR # Detect warnings about ignored "constructor" attributes. gl_WARN_ADD([-Werror], [CFLAGS]) gl_WARN_ADD([-errwarn], [CFLAGS]) @@ -504,6 +506,7 @@ if test "$stdbuf_supported" = "yes" && test -z "$EXEEXT"; then fi CFLAGS=$ac_save_CFLAGS LDFLAGS=$ac_save_LDFLAGS +ac_c_werror_flag=$cu_save_c_werror_flag # Detect when using xlc to determine whether to use -qinclude= AC_CACHE_CHECK([whether the system supports xlc include], [utils_cv_xlc], -- 2.21.0
bug#35650: [PATCH] Improving HP-UX support
Hi Paul, Am 2019-05-11 um 23:14 schrieb Paul Eggert: Thanks for the bug report. I installed the attached patches to coreutils on savannah to fix some (but not all) of the bugs, and some other C99-related bugs I noticed, and have some further comments and questions. * system.h: use __attribute(x) on a GNU-style compiler only * configure.ac, local.mk: use HP aCC-style linker options for libstdbuf I don't see why these patches are needed. 'configure' should arrange for libstdbuf to be built only if you are using GCC. If libstdbuf is being built when you use HP-UX aCC, that suggests there is a bug in 'configure.ac' and we should fix that bug rather than try to port libstdbuf to HP-UX. Here it is w/o the patch: checking whether this system supports stdbuf... yes configure:68555: checking whether this system supports stdbuf configure:68582: /opt/aCC/bin/aCC -AC99 -o conftest -fPIC -g -I/opt/ports/coreutils/include -D_INCLUDE_STDC__SOURCE_199901 -shared -L/opt/ports/cor aCC: warning 901: unknown option: `-fPIC': use +help for online documentation. aCC: warning 901: unknown option: `-hared': use +help for online documentation. aCC: warning 919: "-s" and "-g/-g0/-g1/-G/-p/+I" are mutually exclusive. "-s" option ignored configure:68582: $? = 0 configure:68587: result: yes aCC does not exit with non-zero, it just prints a warning. configure.ac makes false assumptions here at the end. Personally, I don't need stdbuf. If it really should only be compiled with GCC, you should test for GCC only. Drop the hunk for system.h if you think it is not necessary. FORCE_UNSAFE_CONFIGURE=1 gl_cv_have_include_next=no ac_cv_func_getacl=no ac_cv_func_aclsort=no ac_cv_header_sys_bitypes_h=no $CONFIGURE gmake install Why do you need all those flags and why do you need to use gmake? Plain './configure; make' should work. The fact that you need those flags suggests that there is a bug in configure.ac, and it'd be better to fix the underlying bug than to try to paper around it (and possibly introduce further bugs). I agree here, I will take on this in the next round of patches if you don't mind. I wanted to avoid a huge patch in the first place. * I have disabled the compilation of b2sum completely because gmake repeatedly quits with: gmake[2]: *** No rule to make target '/var/tmp/AAA000546.i', needed by 'src/b2sum-md5sum.o'. Stop. gmake[2]: Leaving directory '/tmp/system-compile/gnu/coreutils-8.31' gmake[1]: *** [Makefile:12647: all-recursive] Error 1 gmake[1]: Leaving directory '/tmp/system-compile/gnu/coreutils-8.31' gmake: *** [Makefile:6827: all] Error 2 Presumably your top-level Makefile is messed up somehow. Please investigate the rule for building b2sum that is in 'Makefile', and try to figure out how it got corrupted. It might be a bug in the way 'configure' calls 'sed', or a bug in your 'sed' or 'awk' implementation. Right now, it is a bit awkward. After a 'gmake clean' and 'configure' it works again. I will leave it as-is for now and maybe have a look at it later. * The configuration of PIC and shared library is for HP-UX now. At best autotools would determine that with some default m4 file. Plain './configure; make' should work and if it doesn't work we should fix it. Normally it does not build shared libraries or try to use PIC; although you can arrange for it to do so that is lower priority for us. See above. Michael
bug#35650: [PATCH] Improving HP-UX support
Am 2019-05-10 um 11:49 schrieb Pádraig Brady: On 09/05/19 03:50, Osipov, Michael wrote: diff -ur src/system.h src/system.h --- src/system.h2019-01-05 11:36:22 + +++ src/system.h2019-05-08 15:19:29 + @@ -422,6 +422,10 @@ # endif #endif +#ifndef __GNUC__ +#define __attribute(x) /* empty */ +#endif The only use of __attribute is: src/libstdbuf.c:/* Use __attribute to avoid elision of __attribute__ on SUNPRO_C etc. */ src/libstdbuf.c:static void __attribute ((constructor)) So we should probably have special __hpux handling in that file rather than doing the above. This is all dependent on stdbuf actually working on your platform. Possibly the most appropriate change would be to use __attribute rather than __attribute__ in configure.ac #ifndef ATTRIBUTE_NORETURN # define ATTRIBUTE_NORETURN __attribute__ ((__noreturn__)) #endif --- configure.ac2019-03-04 08:40:55 + +++ configure.ac2019-05-08 15:40:41 + @@ -481,8 +481,8 @@ gl_WARN_ADD([-errwarn], [CFLAGS]) # Put this message here, after gl_WARN_ADD's chatter. AC_MSG_CHECKING([whether this system supports stdbuf]) -CFLAGS="-fPIC $CFLAGS" -LDFLAGS="-shared $LDFLAGS" +CFLAGS="+z $CFLAGS" +LDFLAGS="-b $LDFLAGS" This would need to be conditional, again if stdbuf does actually work on hpux. How try that out? I have it in place and we'll know it in an instant: $ ldd $(which stdbuf) /opt/ports/coreutils/bin/stdbuf: libc.so.1 =>/usr/lib/hpux32/libc.so.1 libdl.so.1 => /usr/lib/hpux32/libdl.so.1 $ ldd /opt/ports/coreutils/libexec/coreutils/libstdbuf.so /opt/ports/coreutils/libexec/coreutils/libstdbuf.so: Regards, Michael
bug#35685: Request
tag 35685 + notabug close 35685 thanks Safdar Iqbal wrote: > Sir,Provide me to installation procedure of wien2k(14.2) on ubuntu > (19.04)sir chmod command cannot excite on my workstation core i7sir > please guide methanks Hello! You are asking about WIEN2k (http://www.wien2k.at/) and also Ubuntu but this is the GNU Coreutils project. We do not know anything about WIEN2k here. As such I can only close the ticket as there isn't anything we can do about it. I am sorry but you will need to contact the WIEN2k people to ask for help about WIEN2k. Good luck! Bob
bug#35654: We've found a vulnerability of gnu chown, please check it and request a cve id for us.
The essence of this report appears to be an attack of the form, can we get the root user to perform an unsafe operation, in this case can we trick root into dereferencing a symbolic link, such as from ./poc to /etc, in order to perform a further action through the symlink. However this is not a bug in chown's -h implementation. Nor is it particular to chown as this could be any other command as the trick to dereference the symlink first before performing whatever action. For example here is a recipe using the same attack but without chown. ln -s /etc /tmp/junk # Now we trick root into reaching through the symlink. # No way root will see this trick coming! rm -f /tmp/junk/* # This removes the files from /etc. The above does not use chown -h but is essentially the same attack. However again this is not a bug in 'rm' nor 'ln'. It is simply trying to trick the superuser into doing unsafe actions. It requires cooperation on the part of root in order to perform the action. But why would the superuser do such silly things? This is very much like Coyote painting a black image on the side of the mountain hoping the Road Runner will mistake it for a tunnel and run into the mountain becoming dinner for Coyote. But the Road Runner never fell for such tricks and neither should the superuser. That it might happen does not make black paint a threat to the Road Runner. The use of 'sudo' does not change the nature of the issue. Only the root user can install sudo and configure it to perform the unsafe actions as you have described. And it also requires a local user to look the superuser in the eye and try to con them up close and personal. Note that this is essentially the same in legacy Unix and in *BSD where symbolic links originated. The community has had decades to poke at them. It is even more interesting to poke at systems that allow environment variables in symbolic links in which case the target is dependent upon the runtime environment variables! The root user is the superuser and with great power comes great responsibility. Extraordinary claims require extraordinary proof. In order for symlinks to be considered as a security vulnerability a more convincing case will need to be presented. Bob
