/dev/shm/run

SUSE Linux Enterprise Server SLES Configure-Administer
1

Hi,

recently rkhunter started to complain about files in /dev/shm/run

Warning: Suspicious file types found in /dev:
/dev/shm/run/zenworks/.sqlanywhere12/sasrv.ini: ASCII text
/dev/shm/run/nscd/group: data
/dev/shm/run/nscd/passwd: data
/dev/shm/run/nscd/services: data
/dev/shm/run/ConsoleKit/database: ASCII text
Warning: Hidden directory found: /dev/shm/run/zenworks/.sqlanywhere12

It started after the latest kernel update on SLES 11:

uname -a
Linux zcm11-2 3.0.101-0.40-default #1 SMP Thu Sep 18 13:09:38 UTC 2014
(44b8c95) x86_64 x86_64 x86_64 GNU/Linux

but what seems strange to me: I updated some of my servers, rebooted - and
rkhunter does not complain. About one or two weeks later I upgraded the
other servers - now rkhunter complaines on these servers.

To me it looks like as if what was in /var/run has changed to /dev/shm/run

I don’t find anything about /dev/shm/run with google - anybody knows what it
is about with /dev/shm/run ?

Thanks,
Mirko

2

I see /dev/shm/run used by some services on semi-current (kernel patched
about two weeks ago) systems. I do not have a good theory on why the
kernel patch would impact this, but there are a lot of things I do not
know. I think you can be assured it is likely not a rootkit.

–
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

3

There was a patch “slessp3-aaa_base” which I guess might have changed this.
It was not marked “interactive”, so it was installed on my servers without a
reboot afterwards. Probably these changes got active when I rebooted because
of the kernel patch…

Thanks,
Mirko

ab wrote:
[color=blue]

I see /dev/shm/run used by some services on semi-current (kernel patched
about two weeks ago) systems. I do not have a good theory on why the
kernel patch would impact this, but there are a lot of things I do not
know. I think you can be assured it is likely not a rootkit.
[/color]

4

[QUOTE=Mirko Guldner;25376]There was a patch “slessp3-aaa_base” which I guess might have changed this.
It was not marked “interactive”, so it was installed on my servers without a
reboot afterwards. Probably these changes got active when I rebooted because
of the kernel patch…
[/QUOTE]

Lines 292-306 of /etc/init.d/boot.localfs

[CODE] # preserve /var/run in case we mount a new /var over it
mkdir -p /dev/shm/run && cp -a /var/run /dev/shm
OLDVARRUN=$(stat -c “%m” /var/run 2>/dev/null)

    # mount the rest
    mount -av -t $nofs -O no_netdev
    rc_status -v1 -r

    # check if we need to restore /var/run
    NEWVARRUN=$(stat -c "%m" /var/run 2>/dev/null)
    if test -n "$OLDVARRUN" -a "$OLDVARRUN" != "$NEWVARRUN"; then
            cp -a /dev/shm/run/ /var
            chmod 755 /var/run
            rm -rf /dev/shm/run
    fi

[/CODE]

:~ # rpm -qf /etc/init.d/boot.localfs
aaa_base-11-6.98.1
:~ # grep aaa_base-11-6.98.1 /var/log/zypp/history 
# 2014-11-26 10:31:55 aaa_base-11-6.98.1.x86_64.rpm installed ok
zing:~ # rpm -q --changelog aaa_base | head
* Wed Nov 12 2014 ro@suse.de
- preserve /var/run if /var is a submount (bnc#900396)

* Thu Sep 25 2014 ro@suse.de
- properly umount nssadmin file system for oes
- do not mix list of filesystems to unmount with already
  unmounted filesystems (bnc#809110)

* Wed Aug 06 2014 ro@suse.de
- in boot.localfs, if fsck supports the "-r" option, use that
:~ #

So /dev/shm/run/ isn’t used by anything during runtime, it’s just a copy of what was in /var/run/ at a certain point during boot.