Problem creating user in loadable module

[Andy Ruch]

Hello,

I'm trying to write a module for my custom service that will execute
as a separate user. However, I'm having problems creating an SELinux user in the
module. When I call make, I get a syntax error. Below is a simple module that reproduces
the problem.

Everything compiles when I comment out the 'allow' line. I can install the module
and see my user in semanage. Everything also compiles when I comment out the
'gen_user' line. It only fails when there is something after the
'gen_user'. 

Can someone tell me the proper syntax for creating a user in a module?


******** BEGIN MODULE  ********

module mytest 1.0;

require {
    sensitivity s0;
    class file { read };
}

type mytest_t;

role mytest_r types { mytest_t };
gen_user( mytest_u, user, mytest_r, s0, s0 )

allow mytest_t self:file read;

******** END MODULE ********


Thanks,
Andrew Ruch

[Dominick Grift]

On Wed, 2012-11-14 at 10:25 -0800, Andy Ruch wrote:
>  Hello,
>  
>  I'm trying to write a module for my custom service that will execute as a separate
> user. However, I'm having problems creating an SELinux user in the module. When I call
> make, I get a syntax error. Below is a simple module that reproduces the problem.
>  
>  Everything compiles when I comment out the 'allow' line. I can install the module
> and see my user in semanage. Everything also compiles when I comment out the
> 'gen_user' line. It only fails when there is something after the
> 'gen_user'. 
>  
>  Can someone tell me the proper syntax for creating a user in a module?
>   
You do not need to create a selinux user for that i believe.

This is a system user. It does not have a login shell

Regardless of the above i will below show you how to create new confined
users

I will touch on two login users. A unprivileged login user and a
restricted login user

The unprivileged login user can login via both the GUI as well as for
example SSH

The restricted login user is designed to only be able to login via SSH.


Simple unpriv login user example:

>  policy_module(myunprivloginuser, 1.0.0)
>  
>  ########################################
>  #
>  # Declarations
>  #
>  
>  role myunprivloginuser_r;
>  
>  userdom_unpriv_user_template(myunprivloginuser) 

Simple restricted login user example:


>  policy_module(myrestrictedloginuser, 1.0.0)
>  
>  ########################################
>  #
>  # Declarations
>  #
>  
>  role myrestrictedloginuser_r;
>  
>  userdom_restricted_user_template(myrestrictedloginuser) 
For both users you may need to create a corresponding .fc source policy
file with just a simple comment in it:

> # no file contexts for this module 
For both modules you will also need to take care of default contexts
That involves creating a file in /etc/selinux/targeted/context/users
that have the same file name as the selinux user name (example
myrestrictedloginuser_u)

the contents can be taken from other default context files that you can
find in that location all you need to do is change the content to
reflect your user

And you need to add a user mapping (example:)

semanage user -a -L s0 -r s0-s0 -R "myrestrictedloginuser_r" -P user
myrestrictedloginuser_u


But again this is not required for your system service (system users) It
is only required for real users

>  
>  ******** BEGIN MODULE  ********
>  
>  module mytest 1.0;
>  
>  require {
>      sensitivity s0;
>      class file { read };
>  }
>  
>  type mytest_t;
>  
>  role mytest_r types { mytest_t };
>  gen_user( mytest_u, user, mytest_r, s0, s0 )
>  
>  allow mytest_t self:file read;
>  
>  ******** END MODULE ********
>  
>  
>  Thanks,
>  Andrew Ruch             
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[Andy Ruch]

Dominick,
 
Thanks for the response.

>  You do not need to create a selinux user for that i believe.
>
>  This is a system user. It does not have a login shell 
 
This service executes as it's own linux user, which doesn't have a login shell.
This user is only used for this service. Because this dedicated linux user is executing
this service, I wanted to create an selinux user to match. 
 
 
>  Regardless of the above i will below show you how to create new
> confined users
>
>  I will touch on two login users. A unprivileged login user and a restricted login user
As mentioned above, this is not a login user.


>  semanage user -a -L s0 -r s0-s0 -R
> "myrestrictedloginuser_r" -P user myrestrictedloginuser_u 
This semanage line is what I was trying to avoid. I would like to create the selinux user
in the module so I can use it in the .fc file.
 
 
I understand the module I included does nothing useful. It was merely a simplified example
of the problem I am experiencing. To reiterate, when I comment out the 'allow'
line, the module compiles. When I comment out the 'gen_user' line, the module
compiles. With both lines active, the module fails to compile. 
 
Thanks,
Andrew

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/14/2012 01:25 PM, Andy Ruch wrote:
>  Hello,
>  
>  I'm trying to write a module for my custom service that will execute as a
>  separate user. However, I'm having problems creating an SELinux user in the
>  module. When I call make, I get a syntax error. Below is a simple module
>  that reproduces the problem.
>  
>  Everything compiles when I comment out the 'allow' line. I can install the
>  module and see my user in semanage. Everything also compiles when I comment
>  out the 'gen_user' line. It only fails when there is something after the
>  'gen_user'.
>  
>  Can someone tell me the proper syntax for creating a user in a module?
>  
>  
>  ******** BEGIN MODULE  ********
>  
>  module mytest 1.0;
>  
>  require { sensitivity s0; class file { read }; }
>  
>  type mytest_t;
>   
role mytest_r;

>  role mytest_r types { mytest_t }; gen_user( mytest_u, user, mytest_r,
> s0,
>  s0 )
>  
>  allow mytest_t self:file read;
>  
>  ******** END MODULE ********
>  
>  
>  Thanks, Andrew Ruch -- selinux mailing list 
>  selinux(a)lists.fedoraproject.org 
>  https://admin.fedoraproject.org/mailman/listinfo/selinux
>  
>   
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>
> iEYEARECAAYFAlCj6KMACgkQrlYvE4MpobMmzwCfakY7UTGIZHWVSuWI6Z6GdCFY
> imYAn2EIjYKY3CaCxSgWfdjViS2sebDM
> =5gwJ
> -----END PGP SIGNATURE-----

[Andy Ruch]

Adding the role line doesn't seem to make a difference. I was under the impression
that the role declaration statement could have associated types on the same line. 


----- Original Message -----
From: Daniel J Walsh <dwalsh(a)redhat.com&gt;
To: Andy Ruch <adruch2002(a)yahoo.com&gt;
Cc: &quot;selinux(a)lists.fedoraproject.org&quot; <selinux(a)lists.fedoraproject.org&gt;
Sent: Wednesday, November 14, 2012 11:53 AM
Subject: Re: Problem creating user in loadable module

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/14/2012 01:25 PM, Andy Ruch wrote:
>  Hello,
>  
>  I'm trying to write a module for my custom service that will execute as a
>  separate user. However, I'm having problems creating an SELinux user in the
>  module. When I call make, I get a syntax error. Below is a simple module
>  that reproduces the problem.
>  
>  Everything compiles when I comment out the 'allow' line. I can install the
>  module and see my user in semanage. Everything also compiles when I comment
>  out the 'gen_user' line. It only fails when there is something after the
>  'gen_user'.
>  
>  Can someone tell me the proper syntax for creating a user in a module?
>  
>  
>  ******** BEGIN MODULE  ********
>  
>  module mytest 1.0;
>  
>  require { sensitivity s0; class file { read }; }
>  
>  type mytest_t;
>   
role mytest_r;

>  role mytest_r types { mytest_t }; gen_user( mytest_u, user, mytest_r,
> s0,
>  s0 )
>  
>  allow mytest_t self:file read;
>  
>  ******** END MODULE ********
>  
>  
>  Thanks, Andrew Ruch -- selinux mailing list 
>  selinux(a)lists.fedoraproject.org 
>  https://admin.fedoraproject.org/mailman/listinfo/selinux
>  
>   
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>
> iEYEARECAAYFAlCj6KMACgkQrlYvE4MpobMmzwCfakY7UTGIZHWVSuWI6Z6GdCFY
> imYAn2EIjYKY3CaCxSgWfdjViS2sebDM
> =5gwJ
> -----END PGP SIGNATURE-----

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This one compiles for me on Fedora 18.

Depends on your compiler,  I think this used to be allowed but newer compilers
force you to specify the role alone.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>
> iEYEARECAAYFAlCj8sMACgkQrlYvE4MpobMHfgCfRCDdLWo1hY4WfYA/uPLzZ1a6
> x2cAoNViELjUDcAa3Ynb65OUMWuf1HJ6
> =LzWJ
> -----END PGP SIGNATURE-----

CPU Spike caused by semanage commands

[Anamitra Dutta Majumdar]

We are in the process of upgrading our product to RHEL6 os. And during
setting of SELinux contexts using semanage commands we see 100 % CPU usage
as below

top - 19:22:33 up  1:00,  1 user,  load average: 1.25, 1.15, 1.58
Tasks: 171 total,   2 running, 169 sleeping,   0 stopped,   0 zombie
Cpu(s): 24.7%us,  0.2%sy,  0.0%ni, 75.2%id,  0.0%wa,  0.0%hi,  0.0%si,
0.0%st
Mem:   6113004k total,  5841096k used,   271908k free,    22600k buffers
Swap:  2047992k total,        0k used,  2047992k free,  5078044k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
                   
                   
 4189 root      20   0  575m 410m 3296 R 100.0  6.9   0:08.17 semanage
                   
                   
   21 root      20   0     0    0    0 S  0.3  0.0   0:00.48 events/2
                   
                   
   60 root      39  19     0    0    0 S  0.3  0.0   0:00.41 khugepaged
                   
                   
 3337 root      20   0 15088 1396 1020 R  0.3  0.0   0:01.29 top
                   
                   
11471 root      39  19     0    0    0 S  0.3  0.0   0:14.53 kipmi0
                   
                   
    1 root      20   0 19396 1532 1208 S  0.0  0.0   0:01.10 init.real
                   
                   
    2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd
                   
                   
    3 root      RT   0     0    0    0 S  0.0  0.0   0:00.03 migration/0
                   
                   
    4 root      20   0     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/0
                   
                   
    5 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/0
                   
                   
    6 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 watchdog/0
                   
                   
    7 root      RT   0     0    0    0 S  0.0  0.0   0:00.09 migration/1
                   
                   
    8 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/1
                   
                   
    9 root      20   0     0    0    0 S  0.0  0.0   0:00.04 ksoftirqd/1
                   
                   
   10 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 watchdog/1
                   
                   
   11 root      RT   0     0    0    0 S  0.0  0.0   0:00.04 migration/2
                   
                   
   12 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/2
                   
                   
   13 root      20   0     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/2
                   
                   
   14 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 watchdog/2
                   
                   
   15 root      RT   0     0    0    0 S  0.0  0.0   0:00.05 migration/3
                   
                   
   16 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/3
                   
                   
   17 root      20   0     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/3
                   
                   
   18 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 watchdog/3
                   
                   
   19 root      20   0     0    0    0 S  0.0  0.0   0:00.00 events/0
                   
                   
   20 root      20   0     0    0    0 S  0.0  0.0   0:00.03 events/1
                   
                   
   22 root      20   0     0    0    0 S  0.0  0.0   0:00.89 events/3
                   
                   
   23 root      20   0     0    0    0 S  0.0  0.0   0:00.00 cpuset
                   
                   
   24 root      20   0     0    0    0 S  0.0  0.0   0:00.00 khelper
                   
                   
   25 root      20   0     0    0    0 S  0.0  0.0   0:00.00 netns
                   
                   
   26 root      20   0     0    0    0 S  0.0  0.0   0:00.00 async/mgr
                   
                   
   27 root      20   0     0    0    0 S  0.0  0.0   0:00.00 pm
                   
                   
   28 root      20   0     0    0    0 S  0.0  0.0   0:00.02 sync_supers
                   
                   
   29 root      20   0     0    0    0 S  0.0  0.0   0:00.01 bdi-default
                   
                   
   30 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kintegrityd/0
                   
                   
   31 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kintegrityd/1
                   
                   
   32 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kintegrityd/2
                   
                   
   33 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kintegrityd/3
                   
                   
You have new mail in /var/spool/mail/root
[root@vos-cm144 ~]# ps -efZ | grep semanage
system_u:system_r:initrc_t:s0   root      4189  4188 96 19:22 ?
00:00:12 /usr/bin/python -Es /usr/sbin/semanage user -a -P user -R
sysadm_r system_r specialuser_u

Is this an expected behavior .

Thanks,
Anamitra

auditd messages appearing on system console

[Anamitra Dutta Majumdar]

We are in the process of transitioning our product from RHEL5 to RHEL6.

Now with the move to RHEL6 we have started to see all the selinux related
messages from auditd appear on the system
Console which is undesirable, in addition to being logged to the audit
logs.

This issue does not exist in the RHEL5 version of our product.

Is there a way to get around this behavior?

Thanks,
Anamitra

auditd messages appearing on system console

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/20/2012 06:55 PM, Anamitra Dutta Majumdar (anmajumd) wrote:
>  
>  We are in the process of transitioning our product from RHEL5 to RHEL6.
>  
>  Now with the move to RHEL6 we have started to see all the selinux related 
>  messages from auditd appear on the system Console which is undesirable, in
>  addition to being logged to the audit logs.
>  
>  This issue does not exist in the RHEL5 version of our product.
>  
>  Is there a way to get around this behavior?
>  
>  Thanks, Anamitra
>  
>  -- selinux mailing list selinux(a)lists.fedoraproject.org 
>  https://admin.fedoraproject.org/mailman/listinfo/selinux
>   
Are you running the auditd daemon?  What kind of messages are you seeing?
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
>
> iEYEARECAAYFAlCsqWUACgkQrlYvE4MpobONRgCgtJDtMYNcuoC5Odhsn3hCAaxq
> SMgAnRIHJZN8WIgp60VhZHnO72diEHPq
> =oZFf
> -----END PGP SIGNATURE-----

CPU Spike caused by semanage commands

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/20/2012 06:02 PM, Anamitra Dutta Majumdar (anmajumd) wrote:
>  
>  We are in the process of upgrading our product to RHEL6 os. And during 
>  setting of SELinux contexts using semanage commands we see 100 % CPU usage 
>  as below
>  
>  top - 19:22:33 up  1:00,  1 user,  load average: 1.25, 1.15, 1.58 Tasks:
>  171 total,   2 running, 169 sleeping,   0 stopped,   0 zombie Cpu(s):
>  24.7%us,  0.2%sy,  0.0%ni, 75.2%id,  0.0%wa,  0.0%hi,  0.0%si, 0.0%st Mem:
>  6113004k total,  5841096k used,   271908k free,    22600k buffers Swap:
>  2047992k total,        0k used,  2047992k free,  5078044k cached
>  
>  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>  
>  
>  4189 root      20   0  575m 410m 3296 R 100.0  6.9   0:08.17 semanage
>  
>  
>  21 root      20   0     0    0    0 S  0.3  0.0   0:00.48 events/2
>  
>  
>  60 root      39  19     0    0    0 S  0.3  0.0   0:00.41 khugepaged
>  
>  
>  3337 root      20   0 15088 1396 1020 R  0.3  0.0   0:01.29 top
>  
>  
>  11471 root      39  19     0    0    0 S  0.3  0.0   0:14.53 kipmi0
>  
>  
>  1 root      20   0 19396 1532 1208 S  0.0  0.0   0:01.10 init.real
>  
>  
>  2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd
>  
>  
>  3 root      RT   0     0    0    0 S  0.0  0.0   0:00.03 migration/0
>  
>  
>  4 root      20   0     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/0
>  
>  
>  5 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/0
>  
>  
>  6 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 watchdog/0
>  
>  
>  7 root      RT   0     0    0    0 S  0.0  0.0   0:00.09 migration/1
>  
>  
>  8 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/1
>  
>  
>  9 root      20   0     0    0    0 S  0.0  0.0   0:00.04 ksoftirqd/1
>  
>  
>  10 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 watchdog/1
>  
>  
>  11 root      RT   0     0    0    0 S  0.0  0.0   0:00.04 migration/2
>  
>  
>  12 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/2
>  
>  
>  13 root      20   0     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/2
>  
>  
>  14 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 watchdog/2
>  
>  
>  15 root      RT   0     0    0    0 S  0.0  0.0   0:00.05 migration/3
>  
>  
>  16 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/3
>  
>  
>  17 root      20   0     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/3
>  
>  
>  18 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 watchdog/3
>  
>  
>  19 root      20   0     0    0    0 S  0.0  0.0   0:00.00 events/0
>  
>  
>  20 root      20   0     0    0    0 S  0.0  0.0   0:00.03 events/1
>  
>  
>  22 root      20   0     0    0    0 S  0.0  0.0   0:00.89 events/3
>  
>  
>  23 root      20   0     0    0    0 S  0.0  0.0   0:00.00 cpuset
>  
>  
>  24 root      20   0     0    0    0 S  0.0  0.0   0:00.00 khelper
>  
>  
>  25 root      20   0     0    0    0 S  0.0  0.0   0:00.00 netns
>  
>  
>  26 root      20   0     0    0    0 S  0.0  0.0   0:00.00 async/mgr
>  
>  
>  27 root      20   0     0    0    0 S  0.0  0.0   0:00.00 pm
>  
>  
>  28 root      20   0     0    0    0 S  0.0  0.0   0:00.02 sync_supers
>  
>  
>  29 root      20   0     0    0    0 S  0.0  0.0   0:00.01 bdi-default
>  
>  
>  30 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kintegrityd/0
>  
>  
>  31 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kintegrityd/1
>  
>  
>  32 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kintegrityd/2
>  
>  
>  33 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kintegrityd/3
>  
>  
>  You have new mail in /var/spool/mail/root [root@vos-cm144 ~]# ps -efZ |
>  grep semanage system_u:system_r:initrc_t:s0   root      4189  4188 96 19:22
>  ? 00:00:12 /usr/bin/python -Es /usr/sbin/semanage user -a -P user -R 
>  sysadm_r system_r specialuser_u
>  
>  Is this an expected behavior .
>  
>  Thanks, Anamitra
>  
>  
>  
>  -- selinux mailing list selinux(a)lists.fedoraproject.org 
>  https://admin.fedoraproject.org/mailman/listinfo/selinux
>   
semanage is performing a recompile of policy which is causing the spike.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
>
> iEYEARECAAYFAlCsqUcACgkQrlYvE4MpobN6hQCgmMOIX7t4oLddImoUwhnByIWm
> SVUAn24d4y61FnMD++L9DGnHUy0cG6pl
> =FWuT
> -----END PGP SIGNATURE-----

CPU Spike caused by semanage commands

[Anamitra Dutta Majumdar]

Dan,

Thanks for your response.

Why would semanage perform a recompile of the policies. Is it possible to
enforce semanage not to recompile the policies in order to prevent the
spike.

Thanks,
Anamitra

On 11/21/12 2:13 AM, "Daniel J Walsh" <dwalsh(a)redhat.com&gt; wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 11/20/2012 06:02 PM, Anamitra Dutta Majumdar (anmajumd) wrote:
> > 
> > We are in the process of upgrading our product to RHEL6 os. And during
> > setting of SELinux contexts using semanage commands we see 100 % CPU
> >usage 
> > as below
> > 
> > top - 19:22:33 up  1:00,  1 user,  load average: 1.25, 1.15, 1.58 Tasks:
> > 171 total,   2 running, 169 sleeping,   0 stopped,   0 zombie Cpu(s):
> > 24.7%us,  0.2%sy,  0.0%ni, 75.2%id,  0.0%wa,  0.0%hi,  0.0%si, 0.0%st
> >Mem:
> > 6113004k total,  5841096k used,   271908k free,    22600k buffers Swap:
> > 2047992k total,        0k used,  2047992k free,  5078044k cached
> > 
> > PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> > 
> > 
> > 4189 root      20   0  575m 410m 3296 R 100.0  6.9   0:08.17 semanage
> > 
> > 
> > 21 root      20   0     0    0    0 S  0.3  0.0   0:00.48 events/2
> > 
> > 
> > 60 root      39  19     0    0    0 S  0.3  0.0   0:00.41 khugepaged
> > 
> > 
> > 3337 root      20   0 15088 1396 1020 R  0.3  0.0   0:01.29 top
> > 
> > 
> > 11471 root      39  19     0    0    0 S  0.3  0.0   0:14.53 kipmi0
> > 
> > 
> > 1 root      20   0 19396 1532 1208 S  0.0  0.0   0:01.10 init.real
> > 
> > 
> > 2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd
> > 
> > 
> > 3 root      RT   0     0    0    0 S  0.0  0.0   0:00.03 migration/0
> > 
> > 
> > 4 root      20   0     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/0
> > 
> > 
> > 5 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/0
> > 
> > 
> > 6 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 watchdog/0
> > 
> > 
> > 7 root      RT   0     0    0    0 S  0.0  0.0   0:00.09 migration/1
> > 
> > 
> > 8 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/1
> > 
> > 
> > 9 root      20   0     0    0    0 S  0.0  0.0   0:00.04 ksoftirqd/1
> > 
> > 
> > 10 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 watchdog/1
> > 
> > 
> > 11 root      RT   0     0    0    0 S  0.0  0.0   0:00.04 migration/2
> > 
> > 
> > 12 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/2
> > 
> > 
> > 13 root      20   0     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/2
> > 
> > 
> > 14 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 watchdog/2
> > 
> > 
> > 15 root      RT   0     0    0    0 S  0.0  0.0   0:00.05 migration/3
> > 
> > 
> > 16 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/3
> > 
> > 
> > 17 root      20   0     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/3
> > 
> > 
> > 18 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 watchdog/3
> > 
> > 
> > 19 root      20   0     0    0    0 S  0.0  0.0   0:00.00 events/0
> > 
> > 
> > 20 root      20   0     0    0    0 S  0.0  0.0   0:00.03 events/1
> > 
> > 
> > 22 root      20   0     0    0    0 S  0.0  0.0   0:00.89 events/3
> > 
> > 
> > 23 root      20   0     0    0    0 S  0.0  0.0   0:00.00 cpuset
> > 
> > 
> > 24 root      20   0     0    0    0 S  0.0  0.0   0:00.00 khelper
> > 
> > 
> > 25 root      20   0     0    0    0 S  0.0  0.0   0:00.00 netns
> > 
> > 
> > 26 root      20   0     0    0    0 S  0.0  0.0   0:00.00 async/mgr
> > 
> > 
> > 27 root      20   0     0    0    0 S  0.0  0.0   0:00.00 pm
> > 
> > 
> > 28 root      20   0     0    0    0 S  0.0  0.0   0:00.02 sync_supers
> > 
> > 
> > 29 root      20   0     0    0    0 S  0.0  0.0   0:00.01 bdi-default
> > 
> > 
> > 30 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kintegrityd/0
> > 
> > 
> > 31 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kintegrityd/1
> > 
> > 
> > 32 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kintegrityd/2
> > 
> > 
> > 33 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kintegrityd/3
> > 
> > 
> > You have new mail in /var/spool/mail/root [root@vos-cm144 ~]# ps -efZ |
> > grep semanage system_u:system_r:initrc_t:s0   root      4189  4188 96
> >19:22
> > ? 00:00:12 /usr/bin/python -Es /usr/sbin/semanage user -a -P user -R
> > sysadm_r system_r specialuser_u
> > 
> > Is this an expected behavior .
> > 
> > Thanks, Anamitra
> > 
> > 
> > 
> > -- selinux mailing list selinux(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/selinux
> > 
> semanage is performing a recompile of policy which is causing the spike.
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.12 (GNU/Linux)
> > Comment: Using GnuPG with undefined - http://www.enigmail.net/
> >
> > iEYEARECAAYFAlCsqUcACgkQrlYvE4MpobN6hQCgmMOIX7t4oLddImoUwhnByIWm
> > SVUAn24d4y61FnMD++L9DGnHUy0cG6pl
> > =FWuT
> > -----END PGP SIGNATURE----- 
>

CPU Spike caused by semanage commands

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/21/2012 12:57 PM, Anamitra Dutta Majumdar (anmajumd) wrote:
>  Dan,
>  
>  Thanks for your response.
>  
>  Why would semanage perform a recompile of the policies. Is it possible to 
>  enforce semanage not to recompile the policies in order to prevent the 
>  spike.
>  
>  Thanks, Anamitra
>  
>  On 11/21/12 2:13 AM, "Daniel J Walsh" <dwalsh(a)redhat.com&gt; wrote:
>  
>  On 11/20/2012 06:02 PM, Anamitra Dutta Majumdar (anmajumd) wrote:
> >>> 
> >>> We are in the process of upgrading our product to RHEL6 os. And
> >>> during setting of SELinux contexts using semanage commands we see 100
> >>> % CPU usage as below
> >>> 
> >>> top - 19:22:33 up  1:00,  1 user,  load average: 1.25, 1.15, 1.58
> >>> Tasks: 171 total,   2 running, 169 sleeping,   0 stopped,   0 zombie
> >>> Cpu(s): 24.7%us,  0.2%sy,  0.0%ni, 75.2%id,  0.0%wa,  0.0%hi,
> >>> 0.0%si, 0.0%st Mem: 6113004k total,  5841096k used,   271908k free,
> >>> 22600k buffers Swap: 2047992k total,        0k used,  2047992k free,
> >>> 5078044k cached
> >>> 
> >>> PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> >>> 
> >>> 
> >>> 4189 root      20   0  575m 410m 3296 R 100.0  6.9   0:08.17
> >>> semanage
> >>> 
> >>> 
> >>> 21 root      20   0     0    0    0 S  0.3  0.0   0:00.48 events/2
> >>> 
> >>> 
> >>> 60 root      39  19     0    0    0 S  0.3  0.0   0:00.41 khugepaged
> >>> 
> >>> 
> >>> 3337 root      20   0 15088 1396 1020 R  0.3  0.0   0:01.29 top
> >>> 
> >>> 
> >>> 11471 root      39  19     0    0    0 S  0.3  0.0   0:14.53 kipmi0
> >>> 
> >>> 
> >>> 1 root      20   0 19396 1532 1208 S  0.0  0.0   0:01.10 init.real
> >>> 
> >>> 
> >>> 2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd
> >>> 
> >>> 
> >>> 3 root      RT   0     0    0    0 S  0.0  0.0   0:00.03 migration/0
> >>> 
> >>> 
> >>> 4 root      20   0     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/0
> >>> 
> >>> 
> >>> 5 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/0
> >>> 
> >>> 
> >>> 6 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 watchdog/0
> >>> 
> >>> 
> >>> 7 root      RT   0     0    0    0 S  0.0  0.0   0:00.09 migration/1
> >>> 
> >>> 
> >>> 8 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/1
> >>> 
> >>> 
> >>> 9 root      20   0     0    0    0 S  0.0  0.0   0:00.04 ksoftirqd/1
> >>> 
> >>> 
> >>> 10 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 watchdog/1
> >>> 
> >>> 
> >>> 11 root      RT   0     0    0    0 S  0.0  0.0   0:00.04
> >>> migration/2
> >>> 
> >>> 
> >>> 12 root      RT   0     0    0    0 S  0.0  0.0   0:00.00
> >>> migration/2
> >>> 
> >>> 
> >>> 13 root      20   0     0    0    0 S  0.0  0.0   0:00.00
> >>> ksoftirqd/2
> >>> 
> >>> 
> >>> 14 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 watchdog/2
> >>> 
> >>> 
> >>> 15 root      RT   0     0    0    0 S  0.0  0.0   0:00.05
> >>> migration/3
> >>> 
> >>> 
> >>> 16 root      RT   0     0    0    0 S  0.0  0.0   0:00.00
> >>> migration/3
> >>> 
> >>> 
> >>> 17 root      20   0     0    0    0 S  0.0  0.0   0:00.00
> >>> ksoftirqd/3
> >>> 
> >>> 
> >>> 18 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 watchdog/3
> >>> 
> >>> 
> >>> 19 root      20   0     0    0    0 S  0.0  0.0   0:00.00 events/0
> >>> 
> >>> 
> >>> 20 root      20   0     0    0    0 S  0.0  0.0   0:00.03 events/1
> >>> 
> >>> 
> >>> 22 root      20   0     0    0    0 S  0.0  0.0   0:00.89 events/3
> >>> 
> >>> 
> >>> 23 root      20   0     0    0    0 S  0.0  0.0   0:00.00 cpuset
> >>> 
> >>> 
> >>> 24 root      20   0     0    0    0 S  0.0  0.0   0:00.00 khelper
> >>> 
> >>> 
> >>> 25 root      20   0     0    0    0 S  0.0  0.0   0:00.00 netns
> >>> 
> >>> 
> >>> 26 root      20   0     0    0    0 S  0.0  0.0   0:00.00 async/mgr
> >>> 
> >>> 
> >>> 27 root      20   0     0    0    0 S  0.0  0.0   0:00.00 pm
> >>> 
> >>> 
> >>> 28 root      20   0     0    0    0 S  0.0  0.0   0:00.02
> >>> sync_supers
> >>> 
> >>> 
> >>> 29 root      20   0     0    0    0 S  0.0  0.0   0:00.01
> >>> bdi-default
> >>> 
> >>> 
> >>> 30 root      20   0     0    0    0 S  0.0  0.0   0:00.00
> >>> kintegrityd/0
> >>> 
> >>> 
> >>> 31 root      20   0     0    0    0 S  0.0  0.0   0:00.00
> >>> kintegrityd/1
> >>> 
> >>> 
> >>> 32 root      20   0     0    0    0 S  0.0  0.0   0:00.00
> >>> kintegrityd/2
> >>> 
> >>> 
> >>> 33 root      20   0     0    0    0 S  0.0  0.0   0:00.00
> >>> kintegrityd/3
> >>> 
> >>> 
> >>> You have new mail in /var/spool/mail/root [root@vos-cm144 ~]# ps -efZ
> >>> | grep semanage system_u:system_r:initrc_t:s0   root      4189  4188
> >>> 96 19:22 ? 00:00:12 /usr/bin/python -Es /usr/sbin/semanage user -a -P
> >>> user -R sysadm_r system_r specialuser_u
> >>> 
> >>> Is this an expected behavior .
> >>> 
> >>> Thanks, Anamitra
> >>> 
> >>> 
> >>> 
> >>> -- selinux mailing list selinux(a)lists.fedoraproject.org 
> >>> https://admin.fedoraproject.org/mailman/listinfo/selinux
> >>> 
>  semanage is performing a recompile of policy which is causing the spike.
>  
>  -- selinux mailing list selinux(a)lists.fedoraproject.org 
>  https://admin.fedoraproject.org/mailman/listinfo/selinux
>   
I am not sure why it is compiling the policy when it adds a file context, it
should be loading the policy to verify that a type exists, but that is all.

Please open a bugzilla on this.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
>
> iEYEARECAAYFAlCtGdwACgkQrlYvE4MpobPJwgCgyTmhzZJeUZjukHJ4HiDzyK28
> r94AoKtdnFA88ASjgXDuu4LnDyP3AtzS
> =hMNU
> -----END PGP SIGNATURE-----