Use only first occurence from /etc/mtab

[jan-cerny]

Description:

The mount options of the first entry will be used.

Rationale:

If there are multiple lines in /etc/mtab that match the same mount point, the variable _previous_mount_opts contained newline characters. These newlines were propagated to /etc/fstab. As a result, an invalid entry in /etc/fstab was created, mount command hasn't been successful and the oscap scan after remediation returned false.

Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1754553

[yuumasato]

If there are multiple lines in /etc/mtab that match the same mount point, the variable _previous_mount_opts contained newline characters.

In what situation there are multiple lines with the same mountpoint?

Does it make sense to have a test scenario for that?

[jan-cerny]

In what situation there are multiple lines with the same mountpoint?

It happened to our team during RHEL7 installation with OSCAP Anaconda Addon with OSPP profile at the moment the Bash remediation for rule mount_option_dev_shm_noexec has been applied.

Does it make sense to have a test scenario for that?

Yes.

[jan-cerny]

I have added a test scenario

[yuumasato]

In what situation there are multiple lines with the same mountpoint?

It happened to our team during RHEL7 installation with OSCAP Anaconda Addon with OSPP profile at the moment the Bash remediation for rule mount_option_dev_shm_noexec has been applied.

@jan-cerny My question was more about how it came to be that there are two entries for the same mount point. Are they identical? If not, is the first one the entry in effect?
Maybe this is a particularity of mounts during Anaconda environment?
I tried the remediation on a VM, and this double entry doesn't happen in /etc/mtab.

[jan-cerny]

They're 3 items, first is different and the other 2 are identical. I don't know which one is in effect.

It also doesn't happen for me on a VM, it happened during system installation.

[vojtapolasek]

Can you post example of how the /etc/mtab looks like? It might be actually valid as shown here.

[jan-cerny]

@vojtapolasek

rootfs / rootfs rw,size=993624k,nr_inodes=248406 0 0
sysfs /sys sysfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
devtmpfs /dev devtmpfs rw,seclabel,nosuid,size=993640k,nr_inodes=248410,mode=755 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev/shm tmpfs rw,seclabel,nosuid,nodev 0 0
devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,seclabel,nosuid,nodev,mode=755 0 0
tmpfs /sys/fs/cgroup tmpfs ro,seclabel,nosuid,nodev,noexec,mode=755 0 0
cgroup /sys/fs/cgroup/systemd cgroup rw,seclabel,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd 0 0
pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0
cgroup /sys/fs/cgroup/pids cgroup rw,seclabel,nosuid,nodev,noexec,relatime,pids 0 0
cgroup /sys/fs/cgroup/net_cls,net_prio cgroup rw,seclabel,nosuid,nodev,noexec,relatime,net_prio,net_cls 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,seclabel,nosuid,nodev,noexec,relatime,cpuacct,cpu 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,seclabel,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/perf_event cgroup rw,seclabel,nosuid,nodev,noexec,relatime,perf_event 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,seclabel,nosuid,nodev,noexec,relatime,blkio 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,seclabel,nosuid,nodev,noexec,relatime,memory 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,seclabel,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,seclabel,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/hugetlb cgroup rw,seclabel,nosuid,nodev,noexec,relatime,hugetlb 0 0
configfs /sys/kernel/config configfs rw,relatime 0 0
/dev/mapper/live-rw / ext4 rw,seclabel,relatime,data=ordered 0 0
rpc_pipefs /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0
selinuxfs /sys/fs/selinux selinuxfs rw,relatime 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=30,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=16397 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
hugetlbfs /dev/hugepages hugetlbfs rw,seclabel,relatime 0 0
mqueue /dev/mqueue mqueue rw,seclabel,relatime 0 0
tmpfs /tmp tmpfs rw,seclabel 0 0
/dev/mapper/VolGroup-LogVol06 / xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/vda1 /boot xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
devtmpfs /dev devtmpfs rw,seclabel,nosuid,size=993640k,nr_inodes=248410,mode=755 0 0
devpts /dev/pts devpts rw,seclabel,relatime,gid=5,mode=620,ptmxmode=000 0 0
devpts /dev/pts devpts rw,seclabel,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /dev/shm tmpfs rw,seclabel,relatime 0 0
tmpfs /dev/shm tmpfs rw,seclabel,relatime 0 0
/dev/mapper/VolGroup-LogVol02 /home xfs rw,seclabel,nosuid,nodev,relatime,attr2,inode64,noquota 0 0
proc /proc proc rw,relatime 0 0
tmpfs /run tmpfs rw,seclabel,nosuid,nodev,mode=755 0 0
sysfs /sys sysfs rw,seclabel,relatime 0 0
selinuxfs /sys/fs/selinux selinuxfs rw,relatime 0 0
/dev/mapper/VolGroup-LogVol01 /tmp xfs rw,seclabel,nosuid,nodev,noexec,relatime,attr2,inode64,noquota 0 0
/dev/mapper/VolGroup-LogVol03 /var xfs rw,seclabel,nodev,relatime,attr2,inode64,noquota 0 0
/dev/mapper/VolGroup-LogVol04 /var/log xfs rw,seclabel,nodev,relatime,attr2,inode64,noquota 0 0
/dev/mapper/VolGroup-LogVol05 /var/log/audit xfs rw,seclabel,nodev,relatime,attr2,inode64,noquota 0 0
/dev/mapper/VolGroup-LogVol7 /var/tmp xfs rw,seclabel,nosuid,nodev,noexec,relatime,attr2,inode64,noquota 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0

[jan-cerny]

I have run a new kickstart installation of RHEL 7 using ospp profile. The remediation for rule mount_option_dev_shm_noexec doesn't break /etc/fstab syntax anymore. However, the rules in the report are evaluated as error and also other rules testing mount options are evaluated as error. After reboot all mount_option.* rules pass. I think it can be a specialty of Anaconda installation environment.

[yuumasato]

After reboot all mount_option.* rules pass.

Great!
The errors in the report of evaluation during Anaconda install can be overlooked if the evaluation after reboot are green. They can be investigated later.

@jan-cerny Thanks for the fix and investigation.