After adding support for relative paths in umount.hal[1] it aborts if built with _FORTIFY_SOURCE=2: # umount.hal /boot/ *** buffer overflow detected ***: umount.hal terminated ======= Backtrace: ========= /lib/libc.so.6(__fortify_fail+0x37)[0x7f346e5127b7] /lib/libc.so.6(+0xe2640)[0x7f346e510640] /lib/libc.so.6(+0xe2cab)[0x7f346e510cab] umount.hal(main+0xaa)[0x400e6a] /lib/libc.so.6(__libc_start_main+0xfd)[0x7f346e44cbbd] umount.hal[0x400cf9] ======= Memory map: ======== [snip] Fortify source is default since gcc-4.3 and thus default build is affected. Problem is that glibc explicitly requires that second argument to realpath(), device_file_or_mount_point in this case, must be larger then PATH_MAX (see info libc: On systems which define `PATH_MAX' ... the buffer must be large enough for a pathname of this size.). Since HAL_PATH_MAX=1024 is smaller then PATH_MAX=4096 this causes this abort. [1] http://cgit.freedesktop.org/hal/commit/?id=6d8eed9015a6ca648fe1dad575621b6ea959a748
I checked the code, and there's indeed a second place which uses realpath() with HAL_PATH_MAX.
http://cgit.freedesktop.org/hal/commit/?id=a2c3dd5a04d79265772c09c4280606d5c2ed72c6
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.