[CentOS] lightdm dependency

2017-09-04 Thread Jon LaBadie 
On a CentOS 7 system I'm trying to install lightdm.
Yum says it requires "glib2(x86-64) >= 2.50.3".
glib2 2.46 is installed but I have not found a
2.50 version.  Have I overlooked it in some repo?

-- 
Jon H. LaBadie j...@labadie.us
 11226 South Shore Rd.  (703) 787-0688 (H)
 Reston, VA  20190  (703) 935-6720 (C)
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Kernel 4.12 and nVidia Driver

2017-09-04 Thread Eugene Poole 
I tried to move to the latest stable kernel (4.12) so I could take 
advantage of my newest custom system (Intel Core I7 6-core; 64 GB RAM; 
MSI nVidia graphics card; 2 - 120 GB SSD; 2 - 4TB WD Black) on a UEFI 
Asrock mother board.


I've had the machine for 3-months but I couldn't get it to work until I 
found out that the Nouveau driver was causing me all the 'hardware' 
issues. I moved to the nVidia driver along with DKMS and all of my 
issues went away until I attempted to upgrade kernel 4.12 ...


It seems that DKMS doesn't automatically upgrade when the kernel is 
upgraded.  Will this issue go away if I change my graphics card to a AMD?


--
Eugene Poole
Woodstock, Georgia

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Problem with IPTABLES logging message to the screen/console

2017-09-04 Thread Jobst Schmalenbach 
Thanks, that fixed it!

It seems it need to go into rc.local, it gets wiped after a reboot due to 
kernel updates.

Jobst


On Sun, Aug 06, 2017 at 08:03:53PM +1000, Anthony K (akcen...@anroet.com) wrote:
> On 02/08/17 13:32, Jobst Schmalenbach wrote:
> > How can I solve this that those messages are NOT printed.
> I think you are after *dmesg -n alert*
> 
> man dmesg
> ...
>-n, --console-level level
>   Set  the level at which printing of messages is done to the
> con???
>   sole.  The level is a level number or abbreviation of the
> level
>   name.  For all supported levels see the --help output.
> 
>   For  example,  -n  1  or  -n alert prevents all messages,
> except
>   emergency (panic) messages, from appearing on the console.
> All
>   levels  of  messages  are  still  written to /proc/kmsg, so
> sys???
>   logd(8) can still be used to control exactly where kernel
> mes???
>   sages  appear.  When the -n option is used, dmesg will not
> print
>   or clear the kernel ring buffer.
> ...
> 
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos

-- 
186,262 miles/second :  Not just a good idea, it's the LAW.

  | |0| |   Jobst Schmalenbach, General Manager
  | | |0|   Barrett & Sales Essentials
  |0|0|0|   +61 3 9533 , POBox 277, Caulfield South, 3162, Australia
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] selinux denial of cgi script with httpd using ssl

2017-09-04 Thread Gregory P. Ennis 

On Tue, Sep 5, 2017 at 9:49 AM, Gregory P. Ennis  wrote:

> Thanks for your help.
>
> I did pick up an additional entry in the audit file :
>
>
> type=AVC msg=audit(1504561395.709:10196): avc:  denied  { execute } for
> pid=19163 comm="/usr/sbin/httpd" name="s.check.cgi" dev="dm-0"
> ino=537182029 scontext=system_u:system_r:httpd_t:s0
> tcontext=unconfined_u:object_r:httpd_sys_content_t:s0 tclass=file
>
> Unfortunately, I am not sure how the above tells me what is wrong.
>


Hi,

Have you then tried passing this message though audit2why ?

Maybe read through https://wiki.centos.org/HowTos/SELinux if you haven't
already.

If you want something simpler maybe try installing setroubleshoot and
setroubleshoot-server.



Thanks to everyone, I am in the process of working through everyone's
suggestions, will post what I find that works.

Greg

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS-virt] Xen CentOS 7.3 server + CentOS 7.3 VM fails to boot after CR updates (applied to VM)!

2017-09-04 Thread Johnny Hughes 
On 09/04/2017 03:59 PM, Kevin Stange wrote:
> On 09/02/2017 08:11 AM, Johnny Hughes wrote:
>> On 09/01/2017 02:41 PM, Kevin Stange wrote:
>>> On 08/31/2017 07:50 AM, PJ Welsh wrote:
 A recently created and fully functional CentOS 7.3 VM fails to boot
 after applying CR updates:
>>> 
 Server OS is CentOS 7.3 using Xen (no CR updates):
 rpm -qa xen\*
 xen-hypervisor-4.6.3-15.el7.x86_64
 xen-4.6.3-15.el7.x86_64
 xen-licenses-4.6.3-15.el7.x86_64
 xen-libs-4.6.3-15.el7.x86_64
 xen-runtime-4.6.3-15.el7.x86_64

 uname -a
 Linux tsxen2.xx.com  4.9.39-29.el7.x86_64 #1 SMP
 Fri Jul 21 15:09:00 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

 Sadly, the other issue is that the grub menu will not display for me to
 select another kernel to see if it is just a kernel issue.

 The dracut prompt does not show any /dev/disk folder either.

>>>
>>> I'm seeing this as well.  My host is 4.9.44-29 and Xen 4.4.4-26 from
>>> testing repo, my guest is 3.10.0-693.1.1.  Guest boots fine with
>>> 514.26.2.  The kernel messages that appear to kick off the failure for
>>> me start with a page allocation failure.  It eventually reaches dracut
>>> failures due to systemd/udev not setting up properly, but I think the
>>> root is this:
>>>
>>> [1.970630] [ cut here ]
>>> [1.970651] WARNING: CPU: 2 PID: 225 at mm/vmalloc.c:131
>>> vmap_page_range_noflush+0x2c1/0x350
>>> [1.970660] Modules linked in:
>>> [1.970668] CPU: 2 PID: 225 Comm: systemd-udevd Not tainted
>>> 3.10.0-693.1.1.el7.x86_64 #1
>>> [1.970677]   8cddc75d 8803e8587bd8
>>> 816a3d91
>>> [1.970688]  8803e8587c18 810879c8 0083811c14e8
>>> 8800066eb000
>>> [1.970698]  0001 8803e86d6940 c000
>>> 
>>> [1.970708] Call Trace:
>>> [1.970725]  [] dump_stack+0x19/0x1b
>>> [1.970736]  [] __warn+0xd8/0x100
>>> [1.970742]  [] warn_slowpath_null+0x1d/0x20
>>> [1.970748]  [] vmap_page_range_noflush+0x2c1/0x350
>>> [1.970758]  [] map_vm_area+0x2e/0x40
>>> [1.970765]  [] __vmalloc_node_range+0x170/0x270
>>> [1.970774]  [] ? module_alloc_update_bounds+0x14/0x70
>>> [1.970781]  [] ? module_alloc_update_bounds+0x14/0x70
>>> [1.970792]  [] module_alloc+0x73/0xd0
>>> [1.970798]  [] ? module_alloc_update_bounds+0x14/0x70
>>> [1.970804]  [] module_alloc_update_bounds+0x14/0x70
>>> [1.970811]  [] load_module+0xb02/0x29e0
>>> [1.970817]  [] ? vmap_page_range_noflush+0x257/0x350
>>> [1.970823]  [] ? map_vm_area+0x2e/0x40
>>> [1.970829]  [] ? __vmalloc_node_range+0x170/0x270
>>> [1.970838]  [] ? SyS_init_module+0x99/0x110
>>> [1.970846]  [] SyS_init_module+0xc5/0x110
>>> [1.970856]  [] system_call_fastpath+0x16/0x1b
>>> [1.970862] ---[ end trace 2117480876ed90d2 ]---
>>> [1.970869] vmalloc: allocation failure, allocated 24576 of 28672 bytes
>>> [1.970874] systemd-udevd: page allocation failure: order:0, mode:0xd2
>>> [1.970883] CPU: 2 PID: 225 Comm: systemd-udevd Tainted: GW
>>>   3.10.0-693.1.1.el7.x86_64 #1
>>> [1.970894]  00d2 8cddc75d 8803e8587c48
>>> 816a3d91
>>> [1.970910]  8803e8587cd8 81188810 8190ea38
>>> 8803e8587c68
>>> [1.970923]  0018 8803e8587ce8 8803e8587c88
>>> 8cddc75d
>>> [1.970939] Call Trace:
>>> [1.970946]  [] dump_stack+0x19/0x1b
>>> [1.970961]  [] warn_alloc_failed+0x110/0x180
>>> [1.970971]  [] __vmalloc_node_range+0x234/0x270
>>> [1.970981]  [] ? module_alloc_update_bounds+0x14/0x70
>>> [1.970989]  [] ? module_alloc_update_bounds+0x14/0x70
>>> [1.970999]  [] module_alloc+0x73/0xd0
>>> [1.971031]  [] ? module_alloc_update_bounds+0x14/0x70
>>> [1.971038]  [] module_alloc_update_bounds+0x14/0x70
>>> [1.971046]  [] load_module+0xb02/0x29e0
>>> [1.971052]  [] ? vmap_page_range_noflush+0x257/0x350
>>> [1.971061]  [] ? map_vm_area+0x2e/0x40
>>> [1.971067]  [] ? __vmalloc_node_range+0x170/0x270
>>> [1.971075]  [] ? SyS_init_module+0x99/0x110
>>> [1.971081]  [] SyS_init_module+0xc5/0x110
>>> [1.971088]  [] system_call_fastpath+0x16/0x1b
>>> [1.971094] Mem-Info:
>>> [1.971103] active_anon:875 inactive_anon:2049 isolated_anon:0
>>> [1.971103]  active_file:791 inactive_file:8841 isolated_file:0
>>> [1.971103]  unevictable:0 dirty:0 writeback:0 unstable:0
>>> [1.971103]  slab_reclaimable:1732 slab_unreclaimable:1629
>>> [1.971103]  mapped:1464 shmem:2053 pagetables:480 bounce:0
>>> [1.971103]  free:4065966 free_pcp:763 free_cma:0
>>> [1.971131] Node 0 DMA free:15912kB min:12kB low:12kB high:16kB
>>> active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB
>>> unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15996kB
>>>

Re: [CentOS] selinux denial of cgi script with httpd using ssl

2017-09-04 Thread James Hogarth 
On 4 September 2017 at 23:12, Alexander Dalloz  wrote:

> Am 04.09.2017 um 23:49 schrieb Gregory P. Ennis:
>
>> Thanks for your help.
>>
>> I did pick up an additional entry in the audit file :
>>
>>
>> type=AVC msg=audit(1504561395.709:10196): avc:  denied  { execute } for
>> pid=19163 comm="/usr/sbin/httpd" name="s.check.cgi" dev="dm-0"
>> ino=537182029 scontext=system_u:system_r:httpd_t:s0
>> tcontext=unconfined_u:object_r:httpd_sys_content_t:s0 tclass=file
>>
>> Unfortunately, I am not sure how the above tells me what is wrong.
>>
>> Greg
>>
>
> From above log entry you see that the file object denied to execute
> ('/var/www/cgi-bin/name.of.script.cgi) has the SELinux context type
> httpd_sys_content_t.
>
> # semanage fcontext -l | grep '/var/www/cgi-bin'
> /var/www/cgi-bin(/.*)? all files
> system_u:object_r:httpd_sys_script_exec_t:s0
> [ ... ]
>
> The permitted type is httpd_sys_script_exec_t.
>
> `restorecon -Rv /var/www/cgi-bin/' can fix it. Or more targeted `chcon -t
> httpd_sys_script_exec_t /var/www/cgi-bin/name.of.script.cgi'.
>
> Both audit2why and audit2allow suggest to activate a boolean which you may
> not want to set as it disables a more fine grained priviledge separation in
> the context of httpd actions.
>
>
>
Don't ever use chcon unless you hate future you or random future team
member when they wonder why things break after a relabelling!
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] selinux denial of cgi script with httpd using ssl

2017-09-04 Thread James Hogarth 
On 4 September 2017 at 22:49, Gregory P. Ennis  wrote:

> Thanks for your help.
>
> I did pick up an additional entry in the audit file :
>
>
> type=AVC msg=audit(1504561395.709:10196): avc:  denied  { execute } for
> pid=19163 comm="/usr/sbin/httpd" name="s.check.cgi" dev="dm-0"
> ino=537182029 scontext=system_u:system_r:httpd_t:s0
> tcontext=unconfined_u:object_r:httpd_sys_content_t:s0 tclass=file
>
> Unfortunately, I am not sure how the above tells me what is wrong.
>
>
Odd it was in the don't audit logs, as I think that should be logged
normally.

Executable scripts should be httpd_sys_script_exec_t rather than
 httpd_sys_content_t, as the latter is just read only content files rather
than something to be executed.

The default policy has the cgi-bin directory contents labelled correctly by
default though ...

Could you please post the output of 'semanage fcontext -lC' ... this will
list any local file context modifications.

You could try restorecon -Rv /var/www to see if that fixes your labelling,
if you've not made any local modifications.

If you have made local modifications to set the contents of cgi-bin to
httpd_sys_content_t then you should remove those with semanage fcontext -d
'/var/www/cgi-bin' or whatever the pattern for the local modification is as
that's incorrect labelling.

While you're checking selinux configuration do a quick
getsebool httpd_enable_cgi ... it's on by default but worth verifying :)
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] selinux denial of cgi script with httpd using ssl

2017-09-04 Thread Alexander Dalloz 

Am 04.09.2017 um 23:49 schrieb Gregory P. Ennis:

Thanks for your help.

I did pick up an additional entry in the audit file :


type=AVC msg=audit(1504561395.709:10196): avc:  denied  { execute } for
pid=19163 comm="/usr/sbin/httpd" name="s.check.cgi" dev="dm-0"
ino=537182029 scontext=system_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:httpd_sys_content_t:s0 tclass=file

Unfortunately, I am not sure how the above tells me what is wrong.

Greg


From above log entry you see that the file object denied to execute 
('/var/www/cgi-bin/name.of.script.cgi) has the SELinux context type 
httpd_sys_content_t.


# semanage fcontext -l | grep '/var/www/cgi-bin'
/var/www/cgi-bin(/.*)? all files 
system_u:object_r:httpd_sys_script_exec_t:s0

[ ... ]

The permitted type is httpd_sys_script_exec_t.

`restorecon -Rv /var/www/cgi-bin/' can fix it. Or more targeted `chcon 
-t httpd_sys_script_exec_t /var/www/cgi-bin/name.of.script.cgi'.


Both audit2why and audit2allow suggest to activate a boolean which you 
may not want to set as it disables a more fine grained priviledge 
separation in the context of httpd actions.


Alexander

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] CentOS nDPI kmod avaliable for testing

2017-09-04 Thread Eliezer Croitoru 
I have been working for quite some time building nDPI iptables module from
vel21ripn for many Linux distributions and
I just finished couple basic tests on the module for CentOS 7 and I am quite
satisfied.
I am looking for other CentOS 7 admins who will want to test this iptables
module.

More details are at:
https://github.com/vel21ripn/nDPI/issues/18

Thanks,
Eliezer


Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: elie...@ngtech.co.il




___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] selinux denial of cgi script with httpd using ssl

2017-09-04 Thread Clint Dilks 
On Tue, Sep 5, 2017 at 9:49 AM, Gregory P. Ennis  wrote:

> Thanks for your help.
>
> I did pick up an additional entry in the audit file :
>
>
> type=AVC msg=audit(1504561395.709:10196): avc:  denied  { execute } for
> pid=19163 comm="/usr/sbin/httpd" name="s.check.cgi" dev="dm-0"
> ino=537182029 scontext=system_u:system_r:httpd_t:s0
> tcontext=unconfined_u:object_r:httpd_sys_content_t:s0 tclass=file
>
> Unfortunately, I am not sure how the above tells me what is wrong.
>


Hi,

Have you then tried passing this message though audit2why ?

Maybe read through https://wiki.centos.org/HowTos/SELinux if you haven't
already.

If you want something simpler maybe try installing setroubleshoot and
setroubleshoot-server.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] selinux denial of cgi script with httpd using ssl

2017-09-04 Thread Gregory P. Ennis 
Thanks for your help.

I did pick up an additional entry in the audit file :


type=AVC msg=audit(1504561395.709:10196): avc:  denied  { execute } for
pid=19163 comm="/usr/sbin/httpd" name="s.check.cgi" dev="dm-0"
ino=537182029 scontext=system_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:httpd_sys_content_t:s0 tclass=file

Unfortunately, I am not sure how the above tells me what is wrong.

Greg

-Original Message-From: Clint Dilks 
Reply-to: CentOS mailing list 
To: CentOS mailing list 
Subject: Re: [CentOS] selinux denial of cgi script with httpd using ssl
Date: Tue, 5 Sep 2017 09:38:27 +1200

HI,

Try disabling Don't Audit rules

semodule -DB

Then check /var/log/audit.log

To re-enable

semodule -B






On Tue, Sep 5, 2017 at 5:07 AM, Gregory P. Ennis  wrote:

> Everyone,
>
> I am trying to use a cgi perl script for a CentOs 7 website that works
> fine with selinux in permissive mode but fails with selinux in enforcing
> mode.
>
> The problem I have is that I can not find where the selinux error
> message is being recorded.
>
> It does not appear to be in the /var/log/messages
> or /var/log/audit/audit.log.  I do not get
> any /var/log/httpd/ssl_error_log entries. I do get a successful entry
> into /var/log/httpd/ssl_access_log and ssl_request_log when selinux is
> in permissive mode, but not when selinux is in enforcing mode.
>
> The only place I can see that I am getting an error message is in the
> /var/log/httpd/error_log which is as follows :
>
> Mon Sep 04 11:40:24.216569 2017] [cgi:error] [pid 2290] [client
> x.x.x.x:55748] AH01215: (13)Permission denied: exec of
> '/var/www/cgi-bin/name.of.script.cgi' failed, referer:
> https://name.domain.com/
>
> When selinux is in permissive mode the above error does not occur and
> the script works fine.  When selinux is in enforcing mode the above
> error occurs, and the cgi script fails to execute.
>
> Is there a way to increase the sensitivity of selinux loging, or is
> there a different place to look for the error that prevents the
> execution of the script.
>
> Your help would be appreciated.
>
> Thanks,
>
> Greg Ennis
>
>
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] selinux denial of cgi script with httpd using ssl

2017-09-04 Thread Clint Dilks 
HI,

Try disabling Don't Audit rules

semodule -DB

Then check /var/log/audit.log

To re-enable

semodule -B






On Tue, Sep 5, 2017 at 5:07 AM, Gregory P. Ennis  wrote:

> Everyone,
>
> I am trying to use a cgi perl script for a CentOs 7 website that works
> fine with selinux in permissive mode but fails with selinux in enforcing
> mode.
>
> The problem I have is that I can not find where the selinux error
> message is being recorded.
>
> It does not appear to be in the /var/log/messages
> or /var/log/audit/audit.log.  I do not get
> any /var/log/httpd/ssl_error_log entries. I do get a successful entry
> into /var/log/httpd/ssl_access_log and ssl_request_log when selinux is
> in permissive mode, but not when selinux is in enforcing mode.
>
> The only place I can see that I am getting an error message is in the
> /var/log/httpd/error_log which is as follows :
>
> Mon Sep 04 11:40:24.216569 2017] [cgi:error] [pid 2290] [client
> x.x.x.x:55748] AH01215: (13)Permission denied: exec of
> '/var/www/cgi-bin/name.of.script.cgi' failed, referer:
> https://name.domain.com/
>
> When selinux is in permissive mode the above error does not occur and
> the script works fine.  When selinux is in enforcing mode the above
> error occurs, and the cgi script fails to execute.
>
> Is there a way to increase the sensitivity of selinux loging, or is
> there a different place to look for the error that prevents the
> execution of the script.
>
> Your help would be appreciated.
>
> Thanks,
>
> Greg Ennis
>
>
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS-virt] Xen CentOS 7.3 server + CentOS 7.3 VM fails to boot after CR updates (applied to VM)!

2017-09-04 Thread Kevin Stange 
On 09/02/2017 08:11 AM, Johnny Hughes wrote:
> On 09/01/2017 02:41 PM, Kevin Stange wrote:
>> On 08/31/2017 07:50 AM, PJ Welsh wrote:
>>> A recently created and fully functional CentOS 7.3 VM fails to boot
>>> after applying CR updates:
>> 
>>> Server OS is CentOS 7.3 using Xen (no CR updates):
>>> rpm -qa xen\*
>>> xen-hypervisor-4.6.3-15.el7.x86_64
>>> xen-4.6.3-15.el7.x86_64
>>> xen-licenses-4.6.3-15.el7.x86_64
>>> xen-libs-4.6.3-15.el7.x86_64
>>> xen-runtime-4.6.3-15.el7.x86_64
>>>
>>> uname -a
>>> Linux tsxen2.xx.com  4.9.39-29.el7.x86_64 #1 SMP
>>> Fri Jul 21 15:09:00 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
>>>
>>> Sadly, the other issue is that the grub menu will not display for me to
>>> select another kernel to see if it is just a kernel issue.
>>>
>>> The dracut prompt does not show any /dev/disk folder either.
>>>
>>
>> I'm seeing this as well.  My host is 4.9.44-29 and Xen 4.4.4-26 from
>> testing repo, my guest is 3.10.0-693.1.1.  Guest boots fine with
>> 514.26.2.  The kernel messages that appear to kick off the failure for
>> me start with a page allocation failure.  It eventually reaches dracut
>> failures due to systemd/udev not setting up properly, but I think the
>> root is this:
>>
>> [1.970630] [ cut here ]
>> [1.970651] WARNING: CPU: 2 PID: 225 at mm/vmalloc.c:131
>> vmap_page_range_noflush+0x2c1/0x350
>> [1.970660] Modules linked in:
>> [1.970668] CPU: 2 PID: 225 Comm: systemd-udevd Not tainted
>> 3.10.0-693.1.1.el7.x86_64 #1
>> [1.970677]   8cddc75d 8803e8587bd8
>> 816a3d91
>> [1.970688]  8803e8587c18 810879c8 0083811c14e8
>> 8800066eb000
>> [1.970698]  0001 8803e86d6940 c000
>> 
>> [1.970708] Call Trace:
>> [1.970725]  [] dump_stack+0x19/0x1b
>> [1.970736]  [] __warn+0xd8/0x100
>> [1.970742]  [] warn_slowpath_null+0x1d/0x20
>> [1.970748]  [] vmap_page_range_noflush+0x2c1/0x350
>> [1.970758]  [] map_vm_area+0x2e/0x40
>> [1.970765]  [] __vmalloc_node_range+0x170/0x270
>> [1.970774]  [] ? module_alloc_update_bounds+0x14/0x70
>> [1.970781]  [] ? module_alloc_update_bounds+0x14/0x70
>> [1.970792]  [] module_alloc+0x73/0xd0
>> [1.970798]  [] ? module_alloc_update_bounds+0x14/0x70
>> [1.970804]  [] module_alloc_update_bounds+0x14/0x70
>> [1.970811]  [] load_module+0xb02/0x29e0
>> [1.970817]  [] ? vmap_page_range_noflush+0x257/0x350
>> [1.970823]  [] ? map_vm_area+0x2e/0x40
>> [1.970829]  [] ? __vmalloc_node_range+0x170/0x270
>> [1.970838]  [] ? SyS_init_module+0x99/0x110
>> [1.970846]  [] SyS_init_module+0xc5/0x110
>> [1.970856]  [] system_call_fastpath+0x16/0x1b
>> [1.970862] ---[ end trace 2117480876ed90d2 ]---
>> [1.970869] vmalloc: allocation failure, allocated 24576 of 28672 bytes
>> [1.970874] systemd-udevd: page allocation failure: order:0, mode:0xd2
>> [1.970883] CPU: 2 PID: 225 Comm: systemd-udevd Tainted: GW
>>   3.10.0-693.1.1.el7.x86_64 #1
>> [1.970894]  00d2 8cddc75d 8803e8587c48
>> 816a3d91
>> [1.970910]  8803e8587cd8 81188810 8190ea38
>> 8803e8587c68
>> [1.970923]  0018 8803e8587ce8 8803e8587c88
>> 8cddc75d
>> [1.970939] Call Trace:
>> [1.970946]  [] dump_stack+0x19/0x1b
>> [1.970961]  [] warn_alloc_failed+0x110/0x180
>> [1.970971]  [] __vmalloc_node_range+0x234/0x270
>> [1.970981]  [] ? module_alloc_update_bounds+0x14/0x70
>> [1.970989]  [] ? module_alloc_update_bounds+0x14/0x70
>> [1.970999]  [] module_alloc+0x73/0xd0
>> [1.971031]  [] ? module_alloc_update_bounds+0x14/0x70
>> [1.971038]  [] module_alloc_update_bounds+0x14/0x70
>> [1.971046]  [] load_module+0xb02/0x29e0
>> [1.971052]  [] ? vmap_page_range_noflush+0x257/0x350
>> [1.971061]  [] ? map_vm_area+0x2e/0x40
>> [1.971067]  [] ? __vmalloc_node_range+0x170/0x270
>> [1.971075]  [] ? SyS_init_module+0x99/0x110
>> [1.971081]  [] SyS_init_module+0xc5/0x110
>> [1.971088]  [] system_call_fastpath+0x16/0x1b
>> [1.971094] Mem-Info:
>> [1.971103] active_anon:875 inactive_anon:2049 isolated_anon:0
>> [1.971103]  active_file:791 inactive_file:8841 isolated_file:0
>> [1.971103]  unevictable:0 dirty:0 writeback:0 unstable:0
>> [1.971103]  slab_reclaimable:1732 slab_unreclaimable:1629
>> [1.971103]  mapped:1464 shmem:2053 pagetables:480 bounce:0
>> [1.971103]  free:4065966 free_pcp:763 free_cma:0
>> [1.971131] Node 0 DMA free:15912kB min:12kB low:12kB high:16kB
>> active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB
>> unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15996kB
>> managed:15912kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB
>> slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB
>>

[CentOS] selinux denial of cgi script with httpd using ssl

2017-09-04 Thread Gregory P. Ennis 
Everyone,

I am trying to use a cgi perl script for a CentOs 7 website that works
fine with selinux in permissive mode but fails with selinux in enforcing
mode.

The problem I have is that I can not find where the selinux error
message is being recorded.

It does not appear to be in the /var/log/messages
or /var/log/audit/audit.log.  I do not get
any /var/log/httpd/ssl_error_log entries. I do get a successful entry
into /var/log/httpd/ssl_access_log and ssl_request_log when selinux is
in permissive mode, but not when selinux is in enforcing mode.

The only place I can see that I am getting an error message is in the
/var/log/httpd/error_log which is as follows :

Mon Sep 04 11:40:24.216569 2017] [cgi:error] [pid 2290] [client
x.x.x.x:55748] AH01215: (13)Permission denied: exec of
'/var/www/cgi-bin/name.of.script.cgi' failed, referer:
https://name.domain.com/

When selinux is in permissive mode the above error does not occur and
the script works fine.  When selinux is in enforcing mode the above
error occurs, and the cgi script fails to execute.

Is there a way to increase the sensitivity of selinux loging, or is
there a different place to look for the error that prevents the
execution of the script.

Your help would be appreciated.

Thanks,

Greg Ennis



___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos