> On Friday, February 21, 2014 9:02 AM, Andy Ruch <adruch2002@xxxxxxxxx> wrote: > > > > > > >> On Friday, February 21, 2014 1:55 AM, Miroslav Grepl > <mgrepl@xxxxxxxxxx> wrote: >> > On 02/20/2014 11:30 PM, Andy Ruch wrote: >>> >>> >>> >>> >>>> On Thursday, February 20, 2014 3:23 PM, Daniel J Walsh >> <dwalsh@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> >>>>>>> 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@xxxxxxxxxxxxxxxxxxxxxxx >>>>>>>>> >> 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@xxxxxxxxxxxxxxxxxxxxxxx >>>>>>> > 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@xxxxxxxxxxxxxxxxxxxxxxx >>> 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@xxxxxxxxxxxxxxxxxxxxxxx > 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. -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
