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@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.
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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
