There is a patch by Red Hat that limits rsyslog capabilities. One capability is CAP_DAC_OVERRIDE, which permits to bypass permission checks. IMHO it should not be dropped even with the patch present, but it sounds like it is. Please also note that there are different versions of that patch available.
My guess is that you have a patched version which drops that capability. We (Adiscon, rsyslog's main sponsor) do not currently apply that patch in our package build process, as it gave a couple of folks trouble. Thus I asked if it works with our native version. In any case, it would make sense for you to contact Red Hat support. HTH Rainer El mié, 30 ago 2023 a las 13:24, Ole Froslie via rsyslog (<rsyslog@lists.adiscon.com>) escribió: > > When logged in as root, I can read the file with its permissions set to > -rw------- , for example using "cat access". This outputs the content of > the file on my terminal screen. > I do not understand the difference between reading with cat , and rsyslog > reading when running as root? > > I agree that it should be possible to configure the system creating the > file and doing the roll, so that the file is readable by others. > On the other hand, these are log files of a security related system so it > is understandable that access is very limited. > > > > > On Wed, 30 Aug 2023 at 11:16, David Lang <da...@lang.hm> wrote: > > > On Wed, 30 Aug 2023, Ole Froslie wrote: > > > > > Since rsyslog is running as root, I thought it should be able to read any > > > file on the system, regardless file permissions? > > > > no, it can (eventually) set permissions so it can read it, which you did > > by > > doing o+r (which also shows that it's not SELinux > > > > but when the file rolls and sets the permissions on the new file, root can > > no > > longer read it. > > > > > Adding rsyslog to the dirsrv group does not solve the problem since the > > > file permissions for the access file only allows the user dirsrv to read > > > /write, not the group dirsrv. > > > -rw-------. 1 dirsrv dirsrv 6007159 Aug 29 10:56 *access* > > > > so it's setting it so that only something running as the user dirsrv can > > read > > it, you need to change the settings in that program. > > > > or as a horrible work around, you could run a second copy of rsyslog as > > the user > > dirsrv to read the file and sent it to your main instance. > > > > but fixing it so that something other that the user dirsrv can read it > > will > > probably be your best option. > > > > David Lang > > > > > -Ole > > > > > > > > > On Tue, 29 Aug 2023 at 19:25, David Lang <da...@lang.hm> wrote: > > > > > >> you have already identified the problem, the files are being created > > with > > >> permissions that prohibit rsyslog from reading them. > > >> > > >> you may be able to add root to the group dirsrv to allow rsyslog to read > > >> them, > > >> otherwise you need to figure out a way to create the files with > > different > > >> permissions. > > >> > > >> David Lang > > >> > > >> On Tue, 29 Aug 2023, Ole Froslie via rsyslog wrote: > > >> > > >>> Hi, > > >>> I am setting up centralized logging from FreeIPA version 4.10.1 running > > >> on > > >>> CentOs. > > >>> I have tried to set up the logging, initially just the access log, > > using > > >>> this config (with domain and ips obfuscated) > > >>> > > >>> module(load="imfile") > > >>> > > >>> > > >>> input(type="imfile" File="/var/log/dirsrv/slapd-MY_DOMAIN/access" > > >>> Tag="ipa-security-log" Facility="local0") > > >>> > > >>> # Forward local facilities > > >>> > > >>> if $syslogfacility >= 16 then @my_ip_adress:514 > > >>> > > >>> When restarting rsyslog with this config , I get error message (with > > >>> servername and domains obfuscated): > > >>> > > >>> Aug 29 10:46:28 myserver.mydomain.net systemd[1]: Starting System > > >> Logging > > >>> Service... > > >>> > > >>> Aug 29 10:46:28 myserver.mydomain.net rsyslogd[12607]: *imfile: on > > >> startup > > >>> file '/var/log/dirsrv/slapd-MY-DOMAIN/access' does not exist but is > > >>> configured in static file monitor - this may indicate a > > misconfiguration. > > >>> If the file appears at a later time, it will automatically be > > processed. > > >>> Reason: Permission denied [v8.2102.0-109.el9]* > > >>> > > >>> Aug 29 10:46:28 myserver.mydomain.net systemd[1]: Started System > > Logging > > >>> Service. > > >>> > > >>> Aug 29 10:46:28 myserver.mydomain.net rsyslogd[12607]: [origin > > >>> software="rsyslogd" swVersion="8.2102.0-109.el9" x-pid="12607" x-info=" > > >>> https://www.rsyslog.com";] start > > >>> > > >>> Aug 29 10:46:28 myserver.mydomain.net rsyslogd[12607]: *imfile: error > > >>> accessing file '/var/log/dirsrv/slapd-MY-DOMAIN/access': Permission > > >> denied > > >>> [v8.2102.0-109.el9]* > > >>> > > >>> Aug 29 10:46:28 myserver.mydomain.net rsyslogd[12607]: *imjournal: > > >> journal > > >>> files changed, reloading... [v8.2102.0-109.el9 try > > >>> https://www.rsyslog.com/e/0 <https://www.rsyslog.com/e/0> ]* > > >>> > > >>> > > >>> I have observed the following, following tips on various threads and > > info > > >>> found on internet. > > >>> > > >>> > > >>> - rsyslog is working as intended when exporting the standard linux > > logs > > >>> - rsyslog is running as root. There is no drop privileges > > configured. I > > >>> have checked this in the /etc/rsyslog.conf, and I also see that > > >> rsyslog is > > >>> running as root when using ps -ef | grep rsyslogd > > >>> - running as root should enable it to read any file > > >>> - > > >>> - I have tried to turn off SELinix, the problem remains the same. I > > >> have > > >>> also checked logs , but there are no signs of SELinux being the > > cause > > >> of > > >>> the problem. > > >>> > > >>> > > >>> - FreeIPA is using its system user dirsrv when creating the files. > > >>> - The ownership of the directories and files are as follows: > > >>> > > >>> drwxr-xr-x. 3 root root 28 Aug 23 15:23 *dirsrv* > > >>> > > >>> drwxrwx--x. 2 dirsrv dirsrv 4096 Aug 28 16:55 *slapd-MY-DOMAIN* > > >>> > > >>> -rw-------. 1 dirsrv dirsrv 6007159 Aug 29 10:56 *access* > > >>> > > >>> > > >>> - I have tried to manually change the access rights of the access > > file > > >>> with chmod o+r access and set chmod o+x on the slapd-directory. This > > >>> removes the error after restart of rsyslog, and rsyslog exports the > > >> logs as > > >>> expected. > > >>> - However, due to the FreeIpa log rotation set-up, new files are > > >> created > > >>> and rotated removing the read access for others, and the logging > > stops > > >>> again. > > >>> > > >>> > > >>> Has anyone seen anything similar, does anyone have any clues about what > > >> the > > >>> cause of this could be? > > >>> > > >>> regards, > > >>> Ole > > >>> _______________________________________________ > > >>> rsyslog mailing list > > >>> https://lists.adiscon.net/mailman/listinfo/rsyslog > > >>> http://www.rsyslog.com/professional-services/ > > >>> What's up with rsyslog? Follow https://twitter.com/rgerhards > > >>> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a > > myriad > > >> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you > > >> DON'T LIKE THAT. > > >>> > > >> > > > > > > _______________________________________________ > rsyslog mailing list > https://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com/professional-services/ > What's up with rsyslog? Follow https://twitter.com/rgerhards > NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of > sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T > LIKE THAT. _______________________________________________ rsyslog mailing list https://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
