# Exim: set gid/uid error since upgrade (4.72 to 4.72-r1)

## elstyr

Hi guys,

after upgrading Exim from 4.72 to 4.72-r1 I ran into a strange issue. I'm running 2 instances of Exim on one same machine. They use different config files (-C) and different ports (25 and 2525). Both Exim's run under the user "mail". The folders into which local mails are being delivered belong to a user "vmail".

Since 4.72-r1 (which, I guess, fixes the recent remote-root bug), the 2nd instance can't setgid/uid to the user "vmail" anymore and thus can't deliver local mails anymore.

Both Exim instances have the same configuration for the local delivery:

```
virtual_localdelivery:

  driver        = appendfile

  directory     = ${lookup mysql{SQL_VUSER_DIR}{$value}fail}/$local_part/Maildir

  user          = ${lookup mysql{SQL_VUSER_UID}{$value}fail}

  group         = ${lookup mysql{SQL_VUSER_GID}{$value}fail}

  mode          = 0660

  maildir_format = true

  delivery_date_add

  envelope_to_add

  return_path_add
```

Both instances use the same binaries.

While the first instance still works fine after the upgrade, I get this error at the second instance:

```
2010-12-20 20:51:03 1PUjcj-0000qi-2O unable to set gid=4812 or uid=4812 (euid=8): local delivery to username <username@domain.com> transport=virtual_localdelivery

2010-12-20 20:51:03 1PUjcj-0000qi-2O failed to read delivery status for username@domain.com from delivery subprocess

2010-12-20 20:51:03 1PUjcj-0000qi-2O appendfile transport process returned non-zero status 0x0100: exit code 1
```

The uid/gid 4812 represents the "vmail" user, owner of the destination folder. The problem is that the second instance can't switch to the other uid/gid anymore, while the first instance still can.

Here's the list of the Exim binaries:

```
# ll /usr/sbin/exi*

-rwxr-xr-x 1 root root  10994 Dec 13 13:36 /usr/sbin/exicyclog*

-rwxr-xr-x 1 root root   5213 Dec 13 13:36 /usr/sbin/exigrep*

-rws--x--x 1 root root 963464 Dec 13 13:36 /usr/sbin/exim*

-rwxr-xr-x 1 root root  14432 Dec 13 13:36 /usr/sbin/exim_dbmbuild*

-rwxr-xr-x 1 root root  18576 Dec 13 13:36 /usr/sbin/exim_dumpdb*

-rwxr-xr-x 1 root root  22712 Dec 13 13:36 /usr/sbin/exim_fixdb*

-rwxr-xr-x 1 root root  18624 Dec 13 13:36 /usr/sbin/exim_lock*

-rwxr-xr-x 1 root root  18592 Dec 13 13:36 /usr/sbin/exim_tidydb*

-rwxr-xr-x 1 root root 150799 Dec 13 13:36 /usr/sbin/eximstats*

-rwxr-xr-x 1 root root   8086 Dec 13 13:36 /usr/sbin/exinext*

-rwxr-xr-x 1 root root  58946 Dec 13 13:36 /usr/sbin/exipick*

-rwxr-xr-x 1 root root   4855 Dec 13 13:36 /usr/sbin/exiqgrep*

-rwxr-xr-x 1 root root   4969 Dec 13 13:36 /usr/sbin/exiqsumm*

-rwxr-xr-x 1 root root   4457 Dec 13 13:36 /usr/sbin/exiwhat*
```

Does anyone have an idea why Exim behaves that way now?

Best regards

elstyr

----------

## elstyr

If someone else stumbles upon this:

The exim 4.72-r1 package contained a fix, that was implemented for/in 4.73. That fix prohibits the usage of the -C or -D command line parameters without some predefinitions, like mentioned in the README.UPDATING of the 4.73/4.74 releases.

As I use the -C parameter for my 2nd Exim instance to let it use another configuration file, I needed to rebuild Exim with a given list of trusted configuration files, so Exim could setuid/setgid again when started with -C /path/to/alternative/config.file.

See: TRUSTED_CONFIG_LIST

Best regards,

elstyr

----------

