[CentOS] Using InstallAnywhere with CentOS? ... anyone
Hi All,I was wondering if anyone else uses InstallAnywhere to create a multi-platform installer for their products. My company does. However we have an official build server that is running CentOS, obviously because it is opensource and easy to update etc. However after we converted our build from an old RedHat 5 server to CentOS and were using InstallAnywhere we found out that it is not officially supported on CentOS but is officially supported on RedHat. This doesn't really make any sense to me since they are the same (or virtually the same). I guess it has to do with the amount of time a company wants to spend testing products on different platforms. All this being said, the main reason for this email is to encourage anyone using InstallAnywhere on CentOS for the designer and build functionality, to request that Flexera support CentOS officially. I only want this in case we have specific issues that arise due to the platform. Although it is true the RedHat users will most likely see the same results, it would be beneficial to have official support. Note that CentOS is support as a runtime or production execution platform. I am speaking mainly of the build and design functionality. Please also note that Flexera has not refused to help me with any of my issues so far. They have been great, but these issues are not OS related, they had to do with the use of their product. Thanks in advance for any help that you may give.KM ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Packaging a library for 64-bit or multilib
How does "make install" with autotools decide which directory libraries should go in? I haven't packaged anything since 32-bit (ie. a few years ago), and I now need to re-package a new version of a library I'd used before with CentOS 6 32-bit on CentOS 7 64-bit. The library is pxlib (http://pxlib.sourceforge.net/), which reads and writes old Borland Paradox database files. I've managed to fix 64-bit issues in the C sources. When I go to package the RPM, it runs configure and make and "make DESTDIR=${RPM_BUILD_ROOT} install". The install step puts the resulting libraries in /usr/lib, not /usr/lib64 where the %files step looks. I'm not familiar with autotools, so I don't know where to look to fix the install step to put the libraries in the correct directory. How does make/configure or whatever figure that out? Do I need to change the %prep step to run autotools to write the correct library directory for configure, or does configure need to be hacked to write the correct directory into the Makefiles? Maybe configure needs to be regenerated with a more recent autotools? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Packaging a library for 64-bit or multilib
Found the problem. The spec file was using "./configure". Replacing that with "%configure" caused it to use the correct libdir variable. It also revealed some more warnings at compile time, so I need to go poke through those. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] sssd logs
We have sssd running on a centos 7 box... its logs of course (?!) go into /can't find any info on where this log directory is configured, or whether it is changeable. Anybody know differently? Cheers ian Disclaimer: This message is intended for the addressee only. It may contain information of a confidential or legally privileged nature. If you have received this message in error please notify the sender and destroy the message immediately. All attachments have been scanned for viruses. However D4t4 Solutions Plc cannot accept liability for any loss or damage you may incur as a result of virus infection. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] sssd logs
On Tue, 21 Aug 2018, Ian Diddams wrote: We have sssd running on a centos 7 box... its logs of course (?!) go into /can't find any info on where this log directory is configured, or whether it is changeable. Anybody know differently? See the -d and -f options in the sssd(8) man page. -- Paul Heinlein heinl...@madboa.com 45°38' N, 122°6' W ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] selinux question
I have a web application which uses sudo to invoke python scripts as the user under which the application runs (NO root access). Is there any reason why sudo would would require sys_ptrace access for this? I only get this violation intermittenly, and not with every call to sudo. Here's the violation: Summary: SELinux is preventing sudo (httpd_t) "sys_ptrace" to (httpd_t). Detailed Description: SELinux denied access requested by sudo. It is not expected that this access is required by sudo and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Contextsystem_u:system_r:httpd_t Target Contextsystem_u:system_r:httpd_t Target ObjectsNone [ capability ] Sourcesudo Source Path /usr/bin/sudo Port Host myhost.mydomain.com Source RPM Packages sudo-1.7.2p1-29.el5_10 Target RPM Packages Policy RPMselinux-policy-2.4.6-351.el5 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing ModeEnforcing Plugin Name catchall Host Name myhost.mydomain.com Platform Linux myhost.mydomain.com 2.6.18-419.el5 #1 SMP Fri Feb 24 22:06:09 UTC 2017 i686 i686 Alert Count 359 First SeenTue Oct 8 09:24:50 2013 Last Seen Tue Aug 21 10:26:26 2018 Local ID 717eb9a4-cc7f-4ed1-b638-5db1a841abe4 Line Numbers Raw Audit Messages host=myhost.mydomain.com type=AVC msg=audit(1534872386.726:9642): avc: denied { sys_ptrace } for pid=8458 comm="sudo" capability=19 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_t:s0 tclass=capability host=myhost.mydomain.com type=SYSCALL msg=audit(1534872386.726:9642): arch=4003 syscall=3 success=yes exit=166 a0=1a a1=b7ff4000 a2=400 a3=89cabf0 items=0 ppid=8979 pid=8458 auid=4294967295 uid=48 gid=48 euid=0 suid=0 fsuid=0 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="sudo" exe="/usr/bin/sudo" subj=system_u:system_r:httpd_t:s0 key=(null) Thank You, Nataraj ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] selinux question
On 08/21/2018 12:27 PM, Nataraj wrote: I have a web application which uses sudo to invoke python scripts as the user under which the application runs (NO root access). Is there any reason why sudo would would require sys_ptrace access for this? I only get this violation intermittenly, and not with every call to sudo. Here's the violation: Most likely you can just dontaudit this access. sys_ptrace is often caused by processes trying to read content in /proc. Summary: SELinux is preventing sudo (httpd_t) "sys_ptrace" to (httpd_t). Detailed Description: SELinux denied access requested by sudo. It is not expected that this access is required by sudo and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Contextsystem_u:system_r:httpd_t Target Contextsystem_u:system_r:httpd_t Target ObjectsNone [ capability ] Sourcesudo Source Path /usr/bin/sudo Port Host myhost.mydomain.com Source RPM Packages sudo-1.7.2p1-29.el5_10 Target RPM Packages Policy RPMselinux-policy-2.4.6-351.el5 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing ModeEnforcing Plugin Name catchall Host Name myhost.mydomain.com Platform Linux myhost.mydomain.com 2.6.18-419.el5 #1 SMP Fri Feb 24 22:06:09 UTC 2017 i686 i686 Alert Count 359 First SeenTue Oct 8 09:24:50 2013 Last Seen Tue Aug 21 10:26:26 2018 Local ID 717eb9a4-cc7f-4ed1-b638-5db1a841abe4 Line Numbers Raw Audit Messages host=myhost.mydomain.com type=AVC msg=audit(1534872386.726:9642): avc: denied { sys_ptrace } for pid=8458 comm="sudo" capability=19 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_t:s0 tclass=capability host=myhost.mydomain.com type=SYSCALL msg=audit(1534872386.726:9642): arch=4003 syscall=3 success=yes exit=166 a0=1a a1=b7ff4000 a2=400 a3=89cabf0 items=0 ppid=8979 pid=8458 auid=4294967295 uid=48 gid=48 euid=0 suid=0 fsuid=0 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="sudo" exe="/usr/bin/sudo" subj=system_u:system_r:httpd_t:s0 key=(null) Thank You, Nataraj ___ 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 question
On Tue, Aug 21, 2018 at 12:27:53PM -0700, Nataraj wrote: > Source RPM Packages sudo-1.7.2p1-29.el5_10 > Policy RPMselinux-policy-2.4.6-351.el5 > Platform Linux myhost.mydomain.com 2.6.18-419.el5 #1 SMP > Fri Feb 24 22:06:09 UTC 2017 i686 i686 CentOS 5 was end of life on 31 March, 2017. There have bee no updates for over a year. Might as well turn off SELinux, you're so behind on security updates it probably doesn't matter. -- Jonathan Billings ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] selinux question
On 08/21/2018 12:41 PM, Jonathan Billings wrote: > On Tue, Aug 21, 2018 at 12:27:53PM -0700, Nataraj wrote: >> Source RPM Packages sudo-1.7.2p1-29.el5_10 >> Policy RPMselinux-policy-2.4.6-351.el5 >> Platform Linux myhost.mydomain.com 2.6.18-419.el5 #1 >> SMP Fri Feb 24 22:06:09 UTC 2017 i686 i686 > CentOS 5 was end of life on 31 March, 2017. There have bee no > updates for over a year. > > Might as well turn off SELinux, you're so behind on security updates > it probably doesn't matter. > Thank you. I'm well aware that CentOS 5 is eol, and hoping to replace this server soon. I'm sitting here right now in heavy smoke (which has been going on since early June) in Northern Ca, just miles from huge fires and have spent the last 3 years rebuilding after damage in a 2015 fire. It kind of shakes up ones life a little bit. In the meantime, keeping selinux enabled helps me to keep the server from getting broken into. Since incoming services are limited for the most part to my userbase, I am doing very well so far. There is no remote login access. Thank you, Nataraj ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] selinux question
On Aug 21, 2018, at 1:27 PM, Nataraj wrote: > > I have a web application which uses sudo to invoke python scripts as the > user under which the application runs (NO root access). Why is the web app not running with that user’s permissions in the first place? If your answer is that it needs root access to bind to port 80, there are two common solutions: 1. Start the service as root, set up the port 80 listener, then drop privileges internally with getpwent(“myuser”) and setuid(my_uid). 2. Use an HTTP[S] proxy server, such as Apache with mod_proxy configured. Bind the actual web app to localhost and a high-numbered random port, then forward external port 80 hits to the internal service. This method has the additional advantage that you can use the path part of the URL to relieves the web app of having to serve hits for the static resources — *.js, *.png, *.css… — which can speed the application up. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] How do I actaully get the current sources from centos-git?
On 08/19/2018 09:39 AM, m...@tdiehl.org wrote: > Hi Johnny, > > On Wed, 15 Aug 2018 joh...@centos.org wrote: > >> The issue is specifically with the ability to push sources to >> git.centos.org in the shadow cache. >> >> I can't do that in the current setup, only Red Hat RCM can. I can push >> text into git, but not binary files to shadow cache. >> >> The only package impacted is centos-release, because it is the only >> package that we actually change the tarball and where I would need to >> push to shadow cache. >> >> If I push the spec changes, but not the shadow cache changes, it renders >> centos-release not buildable. >> >> We are working on an update whereby I will be able to push the changes >> to git.centos.org .. when we get that in place, I will maintain >> centos-release there like all the other packages. >> >> In the mean time, we have a 'unified centos-release' here in git (for >> all c7 arches): >> >> https://github.com/CentOS/sig-core-AltArch/tree/master/centos-release >> >> You will still need to download the SRPM to get the tarball. > > Thanks for the update. > > Will there be some kind of announcement when you are able to push to > git.centos.org? > Yes. I am not sure how quickly it will happen, but it is one of the things that is 'on the list' I'll post here once I can push binary sources signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] selinux question
On 08/21/2018 02:20 PM, Warren Young wrote: > On Aug 21, 2018, at 1:27 PM, Nataraj wrote: >> I have a web application which uses sudo to invoke python scripts as the >> user under which the application runs (NO root access). > Why is the web app not running with that user’s permissions in the first > place? > > If your answer is that it needs root access to bind to port 80, there are two > common solutions: > > 1. Start the service as root, set up the port 80 listener, then drop > privileges internally with getpwent(“myuser”) and setuid(my_uid). > > 2. Use an HTTP[S] proxy server, such as Apache with mod_proxy configured. > Bind the actual web app to localhost and a high-numbered random port, then > forward external port 80 hits to the internal service. This method has the > additional advantage that you can use the path part of the URL to relieves > the web app of having to serve hits for the static resources — *.js, *.png, > *.css… — which can speed the application up. > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos The php code runs as user apache under the webserver. If the php ran as the app users it would have full access to all of the data in the app. Using sudo the app can only invoke one specific python script (which is the command name in the sudoers file) to do what it needs to do, without having access to the rest of the apps data and other python scripts used by other functions in the app). Could be that I'm not seeing something, but this approach seems sensible to me, though I could be convinced otherwise if I could see where running the php as the app users, would make more sense. It could be that giving sudo sys_ptrace access could increase the risk to the security of the system, but giving the php code app user access, increases the risk of data compromise in the app. Thank You, Nataraj ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] selinux question
On Aug 21, 2018, at 4:34 PM, Nataraj wrote: > > On 08/21/2018 02:20 PM, Warren Young wrote: >> On Aug 21, 2018, at 1:27 PM, Nataraj wrote: >>> I have a web application which uses sudo to invoke python scripts as the >>> user under which the application runs (NO root access). >> Why is the web app not running with that user’s permissions in the first >> place? >> > The php code runs as user apache under the webserver. Okay, that’s useful to know, and it’s something we’re just now learning. You’ll get better advice if you include such details when using for help. > If the php ran as the app users it would have full access to all of the data > in the app. …and that’s a problem why, exactly? What could happen if that were allowed? I understand that you’re creating a privilege separation scheme here, but if you want good advice, we need to know what you want to achieve with the scheme and why that is necessary. What resources does this non-php user own that user php must not be allowed to have access to? Once we know that, we can advise on how to protect those resources. > Using sudo the app can only invoke one specific python script (which is the > command name in the sudoers file) to do what it needs to do, without having > access to the rest of the apps data and other python scripts used by other > functions in the app). Another way to go about it would be to have the background service running as the non-php user, then provide access to it over the many IPC mechanisms available in a Linux system: named pipes, SysV message queues, shared memory… Add to that all of the higher-level services available like message-oriented middleware: https://en.wikipedia.org/wiki/Category:Message-oriented_middleware Such services let one process tell another, “Hey, I need you to do something for me,” then wait for the answer, received as a single coherent message. Many of these schemes let you split that worker process off into a separate machine, or even a cluster of machines. That could help you to get off CentOS 5: move the worker process onto a C7 box, then when that’s well-validated, move the PHP bits over. Or, move the PHP bits to a *second* C7 box, and now you’ve got much stronger privilege separation. You may remember all of the ways that Shellshock — a local-only exploit — was able to be exploited over HTTP, because local web app code was using the shell, thus converting it into a remote-exploitable security hole. By separating the worker processes to a separate machine, that now can’t happen on the second box. If the front-end box has no sensitive material on it, that’s enough security: just wipe it and re-image it if it’s ever compromised. However you do this, these mechanisms give you hard privilege separation without SELinux bugging you. > I could be convinced otherwise if I could see where running the php as the > app users, would make more sense. That depends on whether the boundary between user php and this unknown “appuser” is bidirectional or not. If there are things owned by user “php” that “appuser” should not see, then continuing to run the web app as two separate users makes sense. If “appuser” can be said to own everything in the web app, and the only reason you’re converting user php privileges to “appuser” privileges is so you don’t have to give user php access to everything in the web app, then I’d say my prior suggestion holds. Now that I know you’re using PHP, I can recommend something like PHP-FPM: https://php-fpm.org/ That’s the old external project. It’s now part of the PHP core: https://secure.php.net/manual/en/install.fpm.php You’ll have to use the old version with C5, though, as that happened after C5 was released. FPM isn’t the only way to go, just one idea, which happens to be well-supported within the PHP community. Regardless of the exact method, this lets you run your PHP code as a non-php user, letting Apache proxy to it using mod_fcgi. Now you’ve got strong separation between things Apache is allowed to read and things it must talk down through PHP to get access to. > It could be that giving sudo sys_ptrace access could increase the risk to the > security of the system Once you give a process ptrace ability, it’s pretty much game over when it comes to security. The scope of what one process can do to another via ptrace(2) is HGE. I’d very much resist placating SELinux in this way. SELinux might in fact be warning you about a real attack here, which would explain why it’s intermittent. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] grub.cfg
I ran into something with a recent batch of updates on CentOS 7. It seems that possibly one of the kernel updates running dracut changed all of the volume groups in the grub.cfg file making the system unable to boot until I manually edited each line putting it back to the way it was originally. My volume group is called vg_h1 but it changed them all to the default “centos”. Is there a config somewhere I need to edit so this never happens again? Steffan A. Cline stef...@hldns.com 602-793-0014 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos