Bug 734086
Summary: | Cannot allocate memory | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Andreas Schwab <schwab> |
Component: | libselinux | Assignee: | Eric Paris <eparis> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 19 | CC: | dwalsh, eparis, gansalmon, itamar, jan.jeseter, jonathan, kernel-maint, madhu.chinakonda, mgrepl, sdsmall |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-10-08 20:45:12 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Andreas Schwab
2011-08-29 12:27:19 UTC
Was this a low memory system? What is a low memory system? 512 MB or less 512 mb should be plenty for a VM. Was this during an install or an update? Update. I have no idea. Does yum reinstall selinux-policy-targeted Reproduce the error? 768mb appears to be enough for now. This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19 Hello, I have the same problem in F19: # setsebool -P httpd_read_user_content 1 SELinux: Could not load policy file /etc/selinux/targeted/policy/policy.29: Cannot allocate memory /sbin/load_policy: Can't load policy: Cannot allocate memory libsemanage.semanage_reload_policy: load_policy returned error code 2. SELinux: Could not load policy file /etc/selinux/targeted/policy/policy.29: Cannot allocate memory /sbin/load_policy: Can't load policy: Cannot allocate memory libsemanage.semanage_reload_policy: load_policy returned error code 2. Could not change policy booleans What can I do with them? uname -a Linux ... 3.9.9-301.fc19.i686.PAE #1 SMP Thu Jul 4 15:25:09 UTC 2013 i686 i686 i386 GNU/Linux # LC_ALL=C yum reinstall selinux-policy-targeted Loaded plugins: langpacks, refresh-packagekit Resolving Dependencies --> Running transaction check ---> Package selinux-policy-targeted.noarch 0:3.12.1-59.fc19 will be reinstalled --> Finished Dependency Resolution Dependencies Resolved ====================================================================================================================================================== Package Arch Version Repository Size ====================================================================================================================================================== Reinstalling: selinux-policy-targeted noarch 3.12.1-59.fc19 updates 4.0 M Transaction Summary ====================================================================================================================================================== Reinstall 1 Package Total download size: 4.0 M Installed size: 18 M Is this ok [y/d/N]: y Downloading packages: selinux-policy-targeted-3.12.1-59.fc19.noarch.rpm | 4.0 MB 00:00:00 Running transaction check Running transaction test Transaction test succeeded Running transaction Installing : selinux-policy-targeted-3.12.1-59.fc19.noarch 1/1 SELinux: Could not load policy file /etc/selinux/targeted/policy/policy.29: Cannot allocate memory load_policy: Can't load policy: Cannot allocate memory Verifying : selinux-policy-targeted-3.12.1-59.fc19.noarch 1/1 Installed: selinux-policy-targeted.noarch 0:3.12.1-59.fc19 Complete! # Than you for your information JJ How much memory does your machine have? $ free total used free shared buffers cached Mem: 4133340 1254584 2878756 0 71972 598536 -/+ buffers/cache: 584076 3549264 Swap: 5713916 0 5713916 # uname -a Linux ... 3.9.9-302.fc19.i686.PAE #1 SMP Sat Jul 6 13:52:23 UTC 2013 i686 i686 i386 GNU/Linux # setsebool -P httpd_read_user_content 1 SELinux: Could not load policy file /etc/selinux/targeted/policy/policy.29: Cannot allocate memory /sbin/load_policy: Can't load policy: Cannot allocate memory libsemanage.semanage_reload_policy: load_policy returned error code 2. SELinux: Could not load policy file /etc/selinux/targeted/policy/policy.29: Cannot allocate memory /sbin/load_policy: Can't load policy: Cannot allocate memory libsemanage.semanage_reload_policy: load_policy returned error code 2. Could not change policy booleans Anything in dmesg? $ ls -sh /etc/selinux/targeted/policy/policy.29 6.3M /etc/selinux/targeted/policy/policy.29 That's just too big. You need to stop shipping all policy modules and/or tailor what modules get installed to what software is installed on the system so that policy size tracks install size. rpm does have better support for policy these days... That is weird, I get ls -sh /etc/selinux/targeted/policy/policy.29 3.2M /etc/selinux/targeted/policy/policy.29 seinfo Statistics for policy file: /sys/fs/selinux/policy Policy Version & Type: v.28 (binary, mls) Classes: 83 Permissions: 253 Sensitivities: 1 Categories: 1024 Types: 4176 Attributes: 346 Users: 9 Roles: 15 Booleans: 257 Cond. Expr.: 308 Allow: 84352 Neverallow: 0 Auditallow: 12 Dontaudit: 7468 Type_trans: 13513 Type_change: 80 Type_member: 35 Role allow: 34 Role_trans: 708 Range_trans: 4690 Constraints: 97 Validatetrans: 0 Initial SIDs: 27 Fs_use: 25 Genfscon: 91 Portcon: 510 Netifcon: 0 Nodecon: 0 Permissives: 4 Polcap: 2 Of course I am on F20. I am on F19. $ rpm -q selinux-policy-targeted selinux-policy-targeted-3.12.1-63.fc19.noarch $ ls -sh /etc/selinux/targeted/policy/policy.29 6.3M /etc/selinux/targeted/policy/policy.29 Might be sandbox policy that is installed but not disabled. # semodule -d sandbox # semodule -l | grep sandbox sandbox 1.0.0 Disabled sandboxX 1.0.0 This should be fixed in the latest update of policy. Yes, in dmesg I found problem: out of vmalloc space - use vmalloc=<size> to increase size ... Then I added vmalloc=256M (default is 128m) to the end kernel cmd line ... ( vi /etc/default/grub ; grub2-mkconfig -o /boot/grub2/grub.cfg ) reboot and the command: # setsebool -P httpd_read_user_content 1 is not problem now ... Thanks for your inspiration ... cat /proc/meminfo MemTotal: 4133340 kB MemFree: 2873828 kB Buffers: 75064 kB Cached: 534480 kB SwapCached: 0 kB Active: 617476 kB Inactive: 504876 kB Active(anon): 513780 kB Inactive(anon): 20968 kB Active(file): 103696 kB Inactive(file): 483908 kB Unevictable: 0 kB Mlocked: 0 kB HighTotal: 3425160 kB HighFree: 2348220 kB LowTotal: 708180 kB LowFree: 525608 kB SwapTotal: 5713916 kB SwapFree: 5713916 kB Dirty: 68 kB Writeback: 0 kB AnonPages: 512840 kB Mapped: 176428 kB Shmem: 21956 kB Slab: 65332 kB SReclaimable: 34228 kB SUnreclaim: 31104 kB KernelStack: 2880 kB PageTables: 12956 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 7780584 kB Committed_AS: 3112400 kB VmallocTotal: 262144 kB VmallocUsed: 112896 kB VmallocChunk: 127728 kB HardwareCorrupted: 0 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB DirectMap4k: 10232 kB DirectMap2M: 757760 kB (In reply to Daniel Walsh from comment #20) > Might be sandbox policy that is installed but not disabled. > > # semodule -d sandbox > > # semodule -l | grep sandbox > sandbox 1.0.0 Disabled > sandboxX 1.0.0 > > This should be fixed in the latest update of policy. I am trying to figure out what is wrong. I have on my F19 # semodule -l | grep sandbox sandbox 1.0.0 Disabled sandboxX 1.0.0 # ls -sh /etc/selinux/targeted/policy/policy.29 6.3M /etc/selinux/targeted/policy/policy.29 # seinfo Statistics for policy file: /sys/fs/selinux/policy Policy Version & Type: v.28 (binary, mls) Classes: 83 Permissions: 253 Sensitivities: 1 Categories: 1024 Types: 4155 Attributes: 345 Users: 8 Roles: 14 Booleans: 254 Cond. Expr.: 303 Allow: 85979 Neverallow: 0 Auditallow: 132 Dontaudit: 7225 Type_trans: 14626 Type_change: 74 Type_member: 33 Role allow: 33 Role_trans: 703 Range_trans: 4664 Constraints: 97 Validatetrans: 0 Initial SIDs: 27 Fs_use: 25 Genfscon: 91 Portcon: 514 Netifcon: 0 Nodecon: 0 Permissives: 0 Polcap: 2 Eric any ideas why these are different? semodule -d unconfined The explosion in size is caused by the file name transition rules. We need to get these to work with attributes. # semodule -d unconfined sesearch -T | wc 53479 360698 4053309 # semodule -e unconfined # sesearch -T | wc 173079 1196592 13388904 Why so many file name transition rules? Only should be required for a security-unaware application that creates two or more files in the same directory that should have different security contexts. If security-aware, it can specify the security context via setfscreatecon() itself. If files should have same security context, no need for name-based rules. If different directories, can use regular transition rules. Also, someone recently pointed out that filename trans rules aren't supported in optional blocks. Don't know if that matters. We don't support attributes for any transition rules presently, not just filename ones. (In reply to Daniel Walsh from comment #25) > # semodule -d unconfined > sesearch -T | wc > 53479 360698 4053309 > # semodule -e unconfined > # sesearch -T | wc > 173079 1196592 13388904 Yes, you are right. I see the same. We have unconfined domains creating any content causes a transition. Most of the rules are around /dev, /etc and ~/ This is why we see a huge drop in size when we disable unconfined.pp. *********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.11.1-200.fc19. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those. Any update on what is going on here? I'm going to go ahead an close this bug. This is not a kernel bug and hopefully the work Dan did to shrink policy has addressed the issue. |