Setting for /run/lock/ in /etc/permissions.local not respected

I have a legacy application that still uses LCK lock files and creates them in /run/lock/. Until I can figure out how to get it re-compiled to fix it (I’m a C dummy), I need /run/lock/ to be owned by root:lock.

With:

user@localhost:/> grep PERMISSION_SECURITY= /etc/sysconfig/security
PERMISSION_SECURITY="easy local"

I added a line to /etc/permissions.local to accomplish that:

user@localhost:/> grep /run/lock /etc/permissions.local
/run/lock/      root:lock       775

After running `chkstat --system --set’, the application worked as expected. But upon re-booting, /run/lock/ is reset to being owned by root:root.

Digging into it further, I discovered that there is a conflict between /etc/permissions.local and /usr/lib/tmpfiles.d/systemd-suse.conf:

user@localhost:/> grep -1 "d /run/lock " /usr/lib/tmpfiles.d/systemd-suse.conf
# FIXME: move to filesystem ?
d /run/lock 0775 root root -

Changing the relevant line to what I need fixed the issue, for me. As my system runs as a single-user, I have no problem with that. However, for other environments it may be an issue as systemd-suse.conf breaks the PERMISSION_SECURITY scheme.

Are there plans to reconcile these two permission schemes? Or, is this a bug that should be reported?

/run is memory based and its content is lost on reboot. You cannot use /etc/permissions* for it.

Okay. Thank you for the information.

Perhaps a comment could be put in /etc/permissions about that.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.