>> I was able to identify the problem. The short answer is my
“seusers”
>> file didn’t
>> have a “__default__” entry. This caused “selinux.getseuserbyname()” in
>> seobject.py to return the name of the linux user instead of an
>> existing selinux
>> user. This linux user name was never able to match an existing seuser
>> record
>> and caused “libsemanage.dbase_llist_query” to fail. Below is a python
>> command that highlights the issue. Just
>> switch between a user that does exist and one that doesn’t to see the
>> difference.
>>
>> python -c ‘import selinux;rec,oldsename,oldserange =
>> selinux.getseuserbyname(“testuser”);print
>> oldsename;’
>>
>>
>> I now have a solution that allows me to move forward,
>> however I would consider this a bug that could be fixed. Maybe add a
>> check for
>> users that don’t exist or make the “__default__” entry mandatory.
>>
I believe your issue is different than #875169 bug. If I understand
correctly, you fail on
# semanage login -a -s foo_u foo
libsemanage.dbase_llist_query: could not query record value
ValueError: Could not query user for foo_u
which looks correct for me. Not sure where you see a bug in this case.
The #875169 bug is about the user/group check which we have in seobject.py.
>> Dan/Miroslav -- Bugzilla Bug 875169 was reopened in relation
>> to this issue. It’s private so I don’t have any access to add a
comment.
>>
> Let me re-check it. Thank you.
> --
> selinux mailing list
> selinux(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/selinux
As you've described the bug, I would say that is what I'm seeing. This all stems
from not having a "__default__" entry in seusers. This caused the old seuser
check in seobject.py to not find a valid seuser and default to the provided linux user
('foo' in your example). Then I was getting the
"libsemanage.dbase_llist_query" error because 'foo' really couldn't
be found, which is correct. So I think the error really exists in seobject.py in the fact
it's trying to use 'foo' as 'oldsename'.