Information: Forum is in read-only mode
For details and other support options see

Feature Request: PrivDropToGroup / setgroups<->initgroups

This is the place for developers to discuss bugs, new features and everything else about code changes.

Moderator: alorbach

Google Ads

Feature Request: PrivDropToGroup / setgroups<->initgroups

Postby tdoll » Thu May 10, 2012 11:12 pm


i'm working on multi-udp-ports-via-ruleset-solution with the need of different logfiles and for a couple of different user-groups on RHEL-6.2.

rsyslogd will be started as "root" via init.
rsyslogd should not be run as root-user - it could be run as own user via "$PrivDropToUser <rsyslogd-user>". ok.

rsyslogd should not also not run with root-group - it should be run as/with "rsyslogd-group"

on os-level rsyslogd is member of all "user-groups" (supplemantary), which should/could read the resulting logfiles
- these different user-groups are coded in via "$FileCreateMode 0640" and "$FileGroup <user-group>" in each ruleset (=one configfile) and should be used by rsyslogd for creating/writing to those logfiles.

if i use "$PrivDropToUser <rsyslogd-group>", then all supplementary groups "get's lost" (as noted in manual).
this will happen in function "doDropPrivGid" via ... "res = setgroups(0, NULL);"
- this is ugly, because rsyslogd can't access the needed supplementary-groups for "$FileGroup <user-group>" anymore ...

so i googled around and found something, that could do the trick:

int initgroups(const char *user, gid_t group);
The initgroups() function initializes the group access list by reading the group database /etc/group and using
all groups of which user is a member. The additional group group is also added to the list.

while i'm no c-coder and can't provide a working patch for this - but i made it to work for me on v6.2.0 and v6.3.8 with:

/* res = setgroups(0, NULL); */

additional hardcoding:
const char *szUser = "rsyslogd-user\0";
res = initgroups( szUser, iGid );

within function "doDropPrivGid".

with this, rsyslogd is working mainly with "his" primary-group and could sucessful access/write all the different logfiles with "$FileGroup <user-group>" with needed group-rights.

my "hardcode-patch" is working fine for me for about 2 weeks now.

it would be nice, if this could be integrated in rsyslog by someone ...
- maybe via additional statement/function: "$PrivLoadUserGroups" or similar ...

Greetings from Cologne
Posts: 7
Joined: Tue Apr 24, 2012 1:58 pm
Location: Köln

Urgent Question?

  • Pulling out your Hair?
  • Wasting Time and Money?
  • Deadline Approaching?

Google Ads

Return to Developer's Corner

Who is online

Users browsing this forum: No registered users and 0 guests