I was playing around with user_u in the targeted policy on RHEL 6.5. I'm logged in as root in the unconfined context, so I have full ability to change anything I want. I've also switched to permissive mode just in case. I originally had user_u set up to have the MLS/MCS settings "s0:c0.c50". This state was functioning properly with no issues(that I'm aware of). To test changing this with commands, I typed in this:

semanage user -m -r s0:c0.c51 user_u

This ran without any problems, and I was able to verify that it worked correctly with semanage user -l. user_u now has the MLS/MCS of "s0:c0.c51". However, if I try to modify user_u or either of the users tied to user_u(named bob and alice), I get an error that looks like this:

libsemanage.validate_handler: MLS range s0:c0.c50 for Unix user bob exceeds allowed range s0:c0.c51 for SELinux user user_u(No such file or directory).
libsemanage.validate_handler: seuser mapping [bob -> (user_u, s0:c0-c50)] is invalid (No such file or directory).
libsemanage.dbase_llist_iterate: could not iterate over records(No such file or directory).

The confusing part is that s0:c0.c50 'exceeds' s0:c0.c51. If I try to modify user_u, it complains about bob. If I try to delete bob, it complains about alice. If I try to delete alice, it complains about bob. I effectively can't change any of them(through the GUI tools or the command line).

Initially I tried backing out the changes from semanage and going back to user_u with s0:c0.c50, but that didn't work, so I tried s0-s0:c0.c1023, which also didn't work. I noticed the errors never mentioned s0-s0:c0.c1023 so it's like they're failing before really changing user_u's MCS/MLS.

I could only find a few examples that were similar online, and the only one that I found with advice said to delete the user mappings from /etc/selinux/targeted/seusers and to run semodule -B. I tried that, and semodule -B fails with the same error messages. I have also replaced the deleted portions of seusers and tried semodule -B to no avail.

Any thoughts on how to fix this? This was a sandbox environment so it's easy to just go back to the original image, but I won't have that luxury in a deployed environment.

1 Answer 1


A version of this happened to me, similar enough for internet searches anyway. I was not altering the MLS context, but I got odd errors like where that was invalidate like in the original question here:

libsemanage.validate_handler: MLS range s0-s0:c0.c1023 for Unix user elflord exceeds allowed range s0 for SELinux user sysadm_u (No such file or directory).
libsemanage.validate_handler: seuser mapping [elflord -> (sysadm_u, s0-s0:c0.c1023)] is invalid (No such file or directory).
libsemanage.dbase_llist_iterate: could not iterate over records (No such file or directory).

This was from running semodule [-i|-B, and particularly confusing with -i when the module made no mention of sysadm_u.

The cause was previously (and unrelated-ly) trying to add a role to sysadmn_u like this:

semanage user -m -R webadm_r sysadm_u

The man page is ambiguous about the functionality of -R with -m, but evidently it does not modify in the sense of adding a role, it replaces them:

> seinfo -u sysadm_u -x

Users: 1
   user sysadm_u roles webadm_r level s0 range s0;

Whoops, sysadm_r is gone. This also meant elflord could not log in, at least via ssh: Unable to get valid context for elflord is sent over the wire.

What's more, although I did not stipulate -r, that got set to a minimal level s0 range 0, which is what the text of the error seems most concerned about.

The fix was to redo the user modification including the original role(s) and range:

semanage user -m -R { sysadm_r webadm_r } sysadm_u -r s0-s0:c0.c1023

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .