On Friday, February 21, 2014 9:02 AM, Andy Ruch
<adruch2002(a)yahoo.com> wrote:
>
> On Friday, February 21, 2014 1:55 AM, Miroslav Grepl
<mgrepl(a)redhat.com> wrote:
> > On 02/20/2014 11:30 PM, Andy Ruch wrote:
>>
>>
>>
>>
>>> On Thursday, February 20, 2014 3:23 PM, Daniel J Walsh
> <dwalsh(a)redhat.com> wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 02/20/2014 04:44 PM, Andy Ruch wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> On Thursday, February 20, 2014 2:36 PM, Daniel J Walsh
>>>>> <dwalsh(a)redhat.com> wrote:
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> On 02/20/2014 03:46 PM, Andy Ruch wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thursday, February 20, 2014 1:38 PM, Daniel J
Walsh
>>>>> <dwalsh(a)redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>> Hash: SHA1
>>>>>>>
>>>>>>>
>>>>>>> On 02/19/2014 11:56 AM, Andy Ruch wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I have a policy that was originally written
for
> RHEL 6.2.
>>> I’m now
>>>>>>>> trying to upgrade to RHEL 6.5 and I’m having
> problems with
>>>>> semanage. I
>>>>>>>> can install a fresh RHEL 6.5 system with the
> targeted
>>> policy and
>>>>>>>> everything works fine. I then uninstall the
> targeted policy
>>> and
>>>>> install
>>>>>>>> my policy and I can’t link the linux user
and
> selinux user.
>>>>>>>>
>>>>>>>>>> semanage user –a -R sysadm_r -R
staff_r
> -r
>>> s0-s0:c0.c1023
>>>>>>>>>> testuser_u useradd -G wheel testuser
> semanage login
>>> -a -r
>>>>>>>>>> s0-s0:c0.c1023 -s testuser_u
testuser
>>>>>>>> libsemanage.dbase_llist_query: could not
query
> record value
>>>>>>>> /usr/sbin/semanage: Could not query user for
> testuser
>>>>>>>>
>>>>>>>>
>>>>>>>> I have the RHEL 6.5 source code for
libsemanage
> and the
>>> targeted
>>>>> policy
>>>>>>>> but so far I haven't been able to find
> differences that
>>> would
>>>>> affect
>>>>>>>> this problem. Could someone please point me
in
> the right
>>> direction
>>>>> as
>>>>>>>> far as what semanage is expecting? What
would
> prevent
>>> libsemanage
>>>>> from
>>>>>>>> querying for the user?
>>>>>>>>
>>>>>>>> Thanks, Andy
>>>>>>>>
>>>>>>>>
>>>>>>>> -- selinux mailing list
> selinux(a)lists.fedoraproject.org
>>>>>>>>
>
https://admin.fedoraproject.org/mailman/listinfo/selinux
>>>>>>>>
>>>>>>> What does semanage login -l and semanage user -l
> show?
>>> -----BEGIN
>>>>>>> PGP SIGNATURE----- Version: GnuPG v1 Comment:
Using
> GnuPG with
>>>>>>> Thunderbird
>>>>> -
>>>>>>>
http://www.enigmail.net/
>>>>>>>
>>>>>>>
>>> iEYEARECAAYFAlMGZ6gACgkQrlYvE4MpobPPDACfZf1lDin/LicVoZbykbsMS2rX
>>>>>>> OuoAoIIa11SrGGVgJiFblx4aCFjPWF9o =iiCj -----END
PGP
>>> SIGNATURE-----
>>>>>> semanage user -l shows:
>>>>>>
>>>>>>
>>>>>> Labeling MLS/ MLS/ SELinux User Prefix
MCS
> Level
>>> MCS
>>>>>> Range SELinux Roles
>>>>>>
>>>>>> root user s0 s0-s0:c0.c1023
> system_r
>>> system_u
>>>>>> user s0 s0-s0:c0.c1023 system_r
testuser_u
> user
>>>>>> s0 s0-s0:c0.c1023 staff_r sysadm_r user_u
> user
>>>>>> s0 s0 user_r
>>>>>>
>>>>>>
>>>>>>
>>>>>> semanage login -l shows:
>>>>>>
>>>>>>
>>>>>> Login Name SELinux User
> MLS/MCS Range
>>>>>>
>>>>>>
>>>>>> root root
> s0-s0:c0.c1023
>>>>>> system_u system_u
> s0-s0:c0.c1023
>>> --
>>>>>> selinux mailing list selinux(a)lists.fedoraproject.org
>>>>>>
https://admin.fedoraproject.org/mailman/listinfo/selinux
>>>>>>
>>>>>>
>>>>> And the testuser exists in /etc/passwd? -----BEGIN PGP
> SIGNATURE-----
>>>>> Version: GnuPG v1 Comment: Using GnuPG with Thunderbird
-
>>>>>
http://www.enigmail.net/
>>>>>
>>>>>
> iEYEARECAAYFAlMGdVYACgkQrlYvE4MpobPSyQCgkQxSuJh2rUYvkDcNjCo2aeai
>>>>> DugAniPjTv6IbODBn+ADnsIPdpf1M55a =TUJs
>>>>>
>>>>> -----END PGP SIGNATURE-----
>>>>>
>>>>
>>>> Yes. The commands "semanage user -a" and
> "useradd"
>>> appear to work fine.
>>>> It's the "semanage login -a" that has trouble.
>>>>
>>> And this is with the stock policycoreutils or a rebuilt one?
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1
>>> Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
>>>
>>> iEYEARECAAYFAlMGgHUACgkQrlYvE4MpobOltACgqKw0AFB/7VRzT08hJRTh5A2v
>>> i1EAn1oG1gBOGN9R3npTRx7aMdR0fV5H
>>> =gXXZ
>>>
>>> -----END PGP SIGNATURE-----
>>>
>> Stock. Fresh install from RHEL 6.5 image. Then I remove the
selinux-policy
> and selinux-policy-targeted RPMs and add my policy RPMs.
>
>> --
>> selinux mailing list
>> selinux(a)lists.fedoraproject.org
>>
https://admin.fedoraproject.org/mailman/listinfo/selinux
> Probably not related but could you test it in permissive?
>
> Also any chance to strace it and send us your output?
>
> Regards,
> Miroslav
>
Sorry. I should have specified that earlier. This has all been in permissive.
I will work on getting an strace.
--
selinux mailing list
selinux(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
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.
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.