RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 886117 - Add support for numeric IDs for logfile ownership
Summary: Add support for numeric IDs for logfile ownership
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: rsyslog
Version: 6.3
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Tomas Heinrich
QA Contact: Karel Srot
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-12-11 14:46 UTC by Trond H. Amundsen
Modified: 2018-12-03 18:04 UTC (History)
11 users (show)

Fixed In Version: rsyslog-5.8.10-8.el6
Doc Type: Bug Fix
Doc Text:
Cause: Directives used for controlling file owener/group (FileOwner, FileGroup, DirOwner, DirGroup) translate names to numerical IDs only during rsyslogs's startup. Consequence: This process fails if the user information is not available at that point and newly created files are owned by root. Fix: New directives were added that take numerical user IDs and don't depend on the translation process. Result: Log files are assigned correct UID/GID even when user information is not available during rsyslog's startup.
Clone Of:
: 1032198 (view as bug list)
Environment:
Last Closed: 2013-11-21 23:39:52 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1180122 1 None None None 2021-01-20 06:05:38 UTC
Red Hat Product Errata RHBA-2013:1716 0 normal SHIPPED_LIVE rsyslog bug fix update 2013-11-20 21:51:43 UTC

Internal Links: 1180122

Description Trond H. Amundsen 2012-12-11 14:46:11 UTC
Description of problem:
In rhel6, rsyslog is started before sssd at boot. This is a problem if using rsyslog configuration directives such as:

$FileGroup mygroup

Where "mygroup" is not a local group but rather from LDAP, IPA etc. and cached via SSSD. The group isn't available when rsyslog starts, rendering the above config useless. If rsyslog is restartet when sssd is running, it works as expected.

Version-Release number of selected component (if applicable):
rsyslog-5.8.10-2.el6.x86_64
sssd-1.8.0-32.el6.x86_64

How reproducible:
Always.

Steps to Reproduce:
1. Add a file /etc/rsyslog.d/test with the following two lines:
     $FileGroup mygroup
     local1.info  /var/log/test.log
   where mygroup is a group from SSSD. Make sure that /var/log/test.log doesn't exist already
2. Reboot
3. Run: logger -p local1.info "testing 123"
4. Check file perms with: ls -l /var/log/test.log
  
Actual results:
Logfile has group owner root

Expected results:
Logfile has group owner mygroup

Additional info:
Not sure if this bug belongs to rsyslog or sssd. Feel free to change the component to something more appropriate.

Comment 2 RHEL Program Management 2012-12-15 06:48:08 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 3 Najmuddin Chirammal 2013-05-30 07:39:50 UTC
I tried to start SSSD without rsyslog and did not find any issues, can we change the start order of SSSD so it start prior to rsyslog? 

Note: Changed the component to SSSD as the sssd init script which needs the changes. 

From RHEL6.3 machine.

# ls /etc/rc.d/rc3.d/S1* |egrep 'sssd|rsyslog'
/etc/rc.d/rc3.d/S12rsyslog
/etc/rc.d/rc3.d/S13sssd

Comment 4 Jakub Hrozek 2013-05-30 09:49:13 UTC
(In reply to Najmuddin Chirammal from comment #3)
> I tried to start SSSD without rsyslog and did not find any issues, can we
> change the start order of SSSD so it start prior to rsyslog? 
> 

Sorry, I don't think this is a good idea. SSSD might perform some logging in cases the configuration is broken, the certificates don't work etc. This would all be lost if there was no syslog at the time.

I understand the use case, but I think the default of starting syslog first, then sssd is good.

Please note that this case would likely work correctly with the 6.4 version of the SSSD as there is also a cache layer that can be contacted even when sssd is not running. Can you maybe check if the 6.4 version already does what you need?

One other idea would be to amend rsyslog to also understand numeric UIDs and GIDs for directives that affect file ownership. Then the SSSD would not be required to run during startup.

Comment 5 Jakub Hrozek 2013-05-30 09:50:48 UTC
After discussing the issue on IRC with the rsyslog maintainer, he suggested we might also use the imfile - http://www.rsyslog.com/doc/imfile.html for logging the messages on startup.

Comment 6 Tomas Heinrich 2013-05-30 13:55:30 UTC
Generally speaking, I'd prefer rsyslog to start as soon as possible. As Jakub has pointed out, starting sssd before the logger might hide some issues.

Specifically to Trond's issue, I'm not sure what problem your're trying to solve.

Yes, If you change the group specified by FileGroup or the entry in LDAP changes and rsyslog starts before sssd, you wouldn't get the correct group _on newly created files_.
Even if you start rsyslog after sssd and get the correct group, this won't affect any of the already present files and you'd still need to do a chown on them.

The only time I can imagine this working is if you configure everything in a kickstart and never change the group again. Every other scenario requires some manual work (chown-ing files and/or restarting the daemon after change).

The workaround with imfile that Jakub has mentioned is possible but I don't find it particularly pretty.

Trond, do you agree with this or can you elaborate?

Comment 7 Trond H. Amundsen 2013-05-30 14:43:16 UTC
Tomas, the behaviour that you describe is what I'm seeing. If rsyslog isn't restarted manually after reboot the cached SSSD groups are unavailable to rsyslog, so any *new* files will be created with GID=0. I also agree that missing out on SSSD startup logs will be bad.

I'd also like to add that I view this as a corner case, and this is not critical functionality for me. The purpose of this bz was merely to bring the issue to your attention. Perhaps the resolution should just be to document that the group specified with FileGroup needs to be a local group, or at least known to the rsyslog daemon when it is started. I could probably fix this on my end by just adding the same group/GID with no members in /etc/group manually so that the group is known to rsyslog upon startup. But I'm not sure if SSSD will have problems with that (using 'group: files sss' in nsswitch.conf). I could also fix this with a little cron job...

BTW, I really like Jakub's idea to make rsyslog understand numeric UIDs and GIDs. To me, that seems like the best solution, and much cleaner than the imfile hack :)

Comment 8 Jakub Hrozek 2013-05-30 15:13:43 UTC
(In reply to Trond H. Amundsen from comment #7)
> Tomas, the behaviour that you describe is what I'm seeing. If rsyslog isn't
> restarted manually after reboot the cached SSSD groups are unavailable to
> rsyslog, so any *new* files will be created with GID=0. I also agree that
> missing out on SSSD startup logs will be bad.
> 
> I'd also like to add that I view this as a corner case, and this is not
> critical functionality for me. The purpose of this bz was merely to bring
> the issue to your attention. Perhaps the resolution should just be to
> document that the group specified with FileGroup needs to be a local group,
> or at least known to the rsyslog daemon when it is started. 

I think documenting that the group name must be resolvable on startup would be nice.

> I could probably
> fix this on my end by just adding the same group/GID with no members in
> /etc/group manually so that the group is known to rsyslog upon startup. But
> I'm not sure if SSSD will have problems with that (using 'group: files sss'
> in nsswitch.conf). I could also fix this with a little cron job...
> 

I wouldn't recommend adding the same group locally. The way nsswitch works is to return first match, so your LDAP group would be essentially invisible via standard glibc calls.

I think now that you established that the SSSD works in your environment, you could change the boot order locally, I think. Or rely on the memcache sssd layer that is new to 6.4 and is able to return entries even without the sssd running.

> BTW, I really like Jakub's idea to make rsyslog understand numeric UIDs and
> GIDs. To me, that seems like the best solution, and much cleaner than the
> imfile hack :)

Comment 9 Tomas Heinrich 2013-05-30 17:53:15 UTC
(In reply to Trond H. Amundsen from comment #7)
> I'd also like to add that I view this as a corner case, and this is not
> critical functionality for me. The purpose of this bz was merely to bring
> the issue to your attention. Perhaps the resolution should just be to
> document that the group specified with FileGroup needs to be a local group,
> or at least known to the rsyslog daemon when it is started.

I agree that this should be documented.

> BTW, I really like Jakub's idea to make rsyslog understand numeric UIDs and
> GIDs. To me, that seems like the best solution, and much cleaner than the
> imfile hack :)

Adding a suport for numeric IDs (via a separate directive) would be possible, but I'd say this defeats the purpose of having them served through sssd. I guess the best option in such a case is to have a localy defined user / group.

Comment 10 Trond H. Amundsen 2013-05-30 18:02:01 UTC
(In reply to Tomas Heinrich from comment #9)
> Adding a suport for numeric IDs (via a separate directive) would be
> possible, but I'd say this defeats the purpose of having them served through
> sssd.

Only to a degree. Access to the file (for the group members) is still controlled centrally on your LDAP/IPA/AD infrastructure, which to me is the main motivation for using a group served through SSSD.

Comment 11 Jakub Hrozek 2013-05-31 12:32:13 UTC
I think we are now in agreement that the SSSD startup order shall remain after rsyslog in RHEL in the general case. Also in 6.4 the new cache layer would be functional even without the SSSD running and the startup order can be modified locally for 6.3 systems.

There are some enhancements I see such as allowing numeric ID or documenting that the group must be resolvable, but these all belong to rsyslog.

I'm reassigning the bug to the rsyslog component.

Comment 12 Tomas Heinrich 2013-06-06 11:32:53 UTC
I'll add a note to the docs and see to get a new numeric-uid/guid directives into upstream. Together with the sssd feature Jakub has mentioned, this should be a good enough solution.

Getting rsyslog to dynamically refresh the ids would be a too invasive change.

Comment 25 errata-xmlrpc 2013-11-21 23:39:52 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1716.html


Note You need to log in before you can comment on or make changes to this bug.