:::: MENU ::::

build error on bash 4.3.30

During the building operations of bash 4.3.30 using buildroot, some errors may occur:

bashline.o: In function `bash_event_hook':
bashline.c:(.text+0x2328): undefined reference to `rl_signal_event_hook'
bashline.o: In function `bash_execute_unix_command':
bashline.c:(.text+0x2d5c): undefined reference to `rl_executing_keyseq'
bashline.o: In function `bashline_set_event_hook':
bashline.c:(.text+0x3734): undefined reference to `rl_signal_event_hook'
bashline.o: In function `bashline_reset_event_hook':
bashline.c:(.text+0x3748): undefined reference to `rl_signal_event_hook'
bashline.o: In function `initialize_readline':
bashline.c:(.text+0x4464): undefined reference to `rl_filename_stat_hook'
bashline.o: In function `attempt_shell_completion':
bashline.c:(.text+0x4b0c): undefined reference to `rl_filename_stat_hook'
bashline.o: In function `bashline_reset':
bashline.c:(.text+0x4bb8): undefined reference to `rl_filename_stat_hook'
bashline.c:(.text+0x4bc0): undefined reference to `rl_signal_event_hook'
bashline.o: In function `command_word_completion_function':
bashline.c:(.text+0x572c): undefined reference to `rl_filename_stat_hook'
collect2: error: ld returned 1 exit status
make[2]: *** [bash] Error 1

This error may depend on your external toolchain, however solution is as easy as making symlink. Main source of this error comes from readline library. It seems that readline 6.2 & 6 (afaik) do not have above functions.

In buildroot sysroot directory,


libreadline.so exists in usr/lib/arm-linux-gnueabihf and linked to lib/arm-linux-gnueabihf/libreadline.so.6 which also linked to libreadline.so.6.2. Changing this linkage to libreadline.so.6.3:

cp usr/lib/libreadline.so.6.3 lib/arm-linux-gnueabihf/
cd usr/lib
ln -sf libreadline.so.6.3 libreadline.so.6

should solve the build problem.

libcgroup cross-compile error: undefined reference to rpl_realloc

libcgroup is an abstraction of a linux cgroups. Even though standard cross-compile operations are fairly enough:

./configure --host=arm-linux-gnueabihf

During compilation, this error happens:

make[3]: Entering directory `/home/arcelik/1511/tools/libcgroup-0.41/src/daemon'
CC cgrulesengd.o
CCLD cgrulesengd
cgrulesengd.o: In function `cgre_store_unchanged_process':
/home/arcelik/1511/tools/libcgroup-0.41/src/daemon/cgrulesengd.c:310: undefined reference to `rpl_realloc'
cgrulesengd.o: In function `cgre_store_parent_info':
/home/arcelik/1511/tools/libcgroup-0.41/src/daemon/cgrulesengd.c:223: undefined reference to `rpl_realloc'
../../src/.libs/libcgroup.so: undefined reference to `rpl_malloc'
collect2: error: ld returned 1 exit status

undefined reference to rpl_malloc and rpl_realloc error can be fixed by explicitly telling the configure script that malloc and realloc functions are exist. So that, above linking error should not happen.

However, target platform has to be a glibc system to avoid from runtime error in the future.

ac_cv_func_malloc_0_nonnull=yes ac_cv_func_realloc_0_nonnull=yes ./configure --host=arm-linux-gnueabihf

Note: an extension of a linaro toolchain 2014.09 is used while cross-compiling. https://github.com/eckucukoglu/arm-linux-gnueabihf.git

SELinux mode configuration details

There exists some blog posts, articles about SELinux mode configuration already, which easily can be found by searching on google: “how to enable/disable selinux, how to configure selinux”. Moreover, The SELinux Notebook 4th edition has information about SELinux modes and global configuration files, respectively in chapter 2.15 and 3.2.1. However, I think, SELinux has some controversial issues about mode configuration and none of these resources are good enough to clear the mind about confusing SELinux mode configuration.
First of all, linux kernel has some configuration options which allows/disallows SELinux to be disabled/enabled. These options are:

  • CONFIG_SECURITY_SELINUX_BOOTPARAM: This option allows SELinux to be disabled at boot. If this option is selected, SELinux functionality can be disabled with selinux=0 on the kernel command line. Moreover, SELinux boot parameter default value can be changed by setting CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE to 0 or 1, respectively disabling or enabling SELinux at bootup.
  • CONFIG_SECURITY_SELINUX_DISABLE: This option enables writing to a selinuxfs node ‘disable’, which allows SELinux to be disabled at runtime prior to the policy load. That means, kernel will be “capable” to disable SELinux at runtime.  In here, Stephen Smalley claims that /sys/fs/selinux/disable can be triggered by setting SELINUX=disabled in /etc/selinux/config. However modifications on /etc/selinux/config file does not affect system until next boot-up. So that, it is the first confusing thing, since linux kernel commented on this option: “SELinux will remain disabled until the next boot”. I still do not know how to disable SELinux (disable, not permissive) at runtime by the help of this kernel configuration.
  • CONFIG_SECURITY_SELINUX_DEVELOP: With this option enabled, the kernel will start in permissive mode unless you specify enforcing=1 on the kernel command line.

So far, we know that these arguments can be passed to kernel:

  • selinux=1 /* enabled */
  • selinux=0 /* disabled */
  • enforcing=1 /* enabled & enforcing */
  • enforcing=0 /* enabled & permissive */

Additionally, from Dan Walsh’s blogpost, there is also

  • autorelabel=1

boot argument to relabel the system with exact security contexts.
Furthermore, another way to configure SELinux modes is global configuration file: /etc/selinux/config

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.

According to these options, SELinux modes can be changed. However which option overrides the other one is confusing.

Temporarily switching between permissive and enforcing

Two way to switch between permissive and enforcing at runtime. Note that after reboot these options will be overriden by the system defaults. Moreover, switching to permissive/enforcing mode is only applicable unless selinux is disabled.

  • Using selinuxfx
# switching to enforcing
echo 1 > /sys/fs/selinux/enforce
# switching to permissive
echo 0 > /sys/fs/selinux/enforce
  • Using setenforce utility
# switching to enforcing
setenforce 1 /* or setenforce Enforcing */
# switching to permissive
setenforce 0 /* or setenforce Permissive */

Permanently switching SELinux modes

The second confusing thing about SELinux mode configuration is that even though kernel boot parameters override the config file, the exact opposite of this action is also possible. To clarify this options, I have made some tests on my running ARM platform. Note that, I compiled kernel with these configs:

  • No boot parameters and no config file exists, then system boots at Permissive mode. CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE & CONFIG_SECURITY_SELINUX_DEVELOP configurations are the reason of that. In fact, selinux=1 is passed as default.
  • None or selinux=1 as boot parameters and SELINUX=enforcing in config file, then system boots at Enforcing.
  • None or selinux=1 as boot parameters and SELINUX=permissive in config file, then system boots at Permissive.
  • None or selinux=1 as boot parameters and SELINUX=disabled in config file, SELinux:  Disabled at runtime.
  • If selinux=0 passed as kernel boot parameter, then SELinux will be disabled whatever passed in config file. However, it is not recommended.
  • enforcing=0 as boot parameter, SELINUX=enforcing in config file, then system boots at Permissive mode.
  • enforcing=0 as boot parameter, SELINUX=disabled in config file, then SELinux:  Disabled at runtime.
  • enforcing=1 passed as boot parameter, SELINUX=permissive in config file, then system boots at Enforcing mode.
  • enforcing=1 passed as boot parameter, SELINUX=disabled in config file, then unexpectedly: SELinux:  Disabled at runtime and kernel panic occurs since can’t load SELinux Policy. I do not know the exact reason of this error. I actually tried to relabel filesystem before enforcing the system, so expected result of this action should be Enforcing system boot-up.

So, boot argument selinux=0 overrides /etc/config/selinux, however selinux=1 does not overrides. Moreover, while passing enforcing=0, even though in /etc/selinux/config includes SELINUX=enforcing, system starts w/ permissive mode. However if config file includes SELINUX=disabled, system starts w/o SELinux. I think this is confusing and kind of inconsistent but there should be a good rationale for that. Most people hardly ever get confronted with these situations.

Switching from disabled to enabled

As mentioned gentoo:selinux tutorials and here, If system booted with SELinux disabled, we need to relabel filesystem to enable again SELinux. After disabling SELinux, switching back to enforcing mode causes kernel crash, since relabeling can not be possible in enforcing mode. So that, switching from disabled to enabled mode is only possible in permissive mode. After booting in permissive mode:

fixfiles relabel

can be used to relabel filesystem. Also, kernel boot parameter


will force the system to relabel, too. In my experiments, after disabling SELinux, passing enforcing=1 as kernel parameters causes kernel panic (as expected). Here the logs:

[ 8.245513] SELinux: Disabled at runtime.
[ 8.474853] type=1404 audit(946686015.345:2): selinux=0 auid=4294967295 ses=4294967295
can't load SELinux Policy. Machine is in enforcing mode. Halting now.

So, what’s the conclusion?

If your intention is to disable SELinux permanently, and never ever want to be enabled again, even though it is not recommended, passing selinux=0 as kernel boot parameter is the best option. For this case, kernel boot argument overrides options in /etc/selinux/config. However, unless SELinux is intented to be disabled, passing selinux=1 or none as kernel boot parameter and modifying /etc/selinux/config file, according to intention, will be proper action.

How to extend the size of an image

In linux, it is possible to extend the size of a disk image without losing already existed content.
For example, to extend rootfs image to a fixed 1GB size:

dd if=/dev/zero of=rootfs.ext2 bs=1M seek=1000 count=0
e2fsck -f rootfs.ext2
resize2fs rootfs.ext2

redirection vs pipe

Redirection (>, <) and pipe (|), both are used to pass output of a process. However, there exists one fundamental differences between them. Even though redirection can be used to pass to stream which also can be a file, pipe can pass output of a process to another process.

For example, this command does that:

dmesg | grep selinux > temp.log
  1. executes dmesg
  2. passes output of dmesg to grep process
  3. executes grep on output of dmesg and take selinux as a pattern
  4. then redirects output of grep to a file named temp.log, if does not exists, creates it.

In fact, above-command can be typed like that:

dmesg > dmesg.out && grep selinux < dmesg.out > temp.log

Which does same job, except that it writes dmesg output to file named dmesg.out. Instead of double redirection, using pipe eases our job.