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
-----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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
What does semanage login -l and semanage user -l show?
On Thursday, February 20, 2014 1:38 PM, Daniel J Walsh dwalsh@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@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
-----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@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@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
And the testuser exists in /etc/passwd?
On Thursday, February 20, 2014 2:36 PM, Daniel J Walsh dwalsh@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
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@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
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@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.
-----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@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
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@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
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@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?
On Thursday, February 20, 2014 3:23 PM, Daniel J Walsh dwalsh@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@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
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@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
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@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.
On 02/20/2014 11:30 PM, Andy Ruch wrote:
On Thursday, February 20, 2014 3:23 PM, Daniel J Walsh dwalsh@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@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
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@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
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@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@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
On Friday, February 21, 2014 1:55 AM, Miroslav Grepl mgrepl@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@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@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
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@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@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@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.
On Friday, February 21, 2014 9:02 AM, Andy Ruch adruch2002@yahoo.com wrote:
On Friday, February 21, 2014 1:55 AM, Miroslav Grepl
mgrepl@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@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@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@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@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@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
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@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@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.
On 03/28/2014 04:33 PM, Andy Ruch wrote:
On Friday, February 21, 2014 9:02 AM, Andy Ruch adruch2002@yahoo.com wrote:
On Friday, February 21, 2014 1:55 AM, Miroslav Grepl
mgrepl@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@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@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@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@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@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@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@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.
Let me re-check it. Thank you.
On 03/31/2014 03:10 PM, Miroslav Grepl wrote:
On 03/28/2014 04:33 PM, Andy Ruch wrote:
On Friday, February 21, 2014 9:02 AM, Andy Ruch adruch2002@yahoo.com wrote:
On Friday, February 21, 2014 1:55 AM, Miroslav Grepl
mgrepl@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@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@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@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@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@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@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@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.
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@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.
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@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'.
On 04/01/2014 08:27 PM, Andy Ruch wrote:
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@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'.
Yes, it comes from getseuserbyname().
On 04/01/2014 08:27 PM, Andy Ruch wrote:
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@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'.
I have been playing more with this issue. And I believe we want to have something like
# semanage login -a -r s0-s0:c0.c1023 -s testuser_u testuser /usr/sbin/semanage: There is no "__default__" entry defined in seusers config file.
On 03/31/2014 03:10 PM, Miroslav Grepl wrote:
On 03/28/2014 04:33 PM, Andy Ruch wrote:
On Friday, February 21, 2014 9:02 AM, Andy Ruch adruch2002@yahoo.com wrote:
On Friday, February 21, 2014 1:55 AM, Miroslav Grepl
mgrepl@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@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@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@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@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@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@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@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.
Actually I need to re-check this scenario.
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.
Let me re-check it. Thank you.
selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
selinux@lists.fedoraproject.org