Bug #13237


dhcp6c script cannot be executed safely

Added by Denny Page 2 months ago. Updated 2 months ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:


22.05 Plus Beta on system boot

When the "Do not wait for a RA" option is selected on the WAN interface, /var/etc/dhcp6c.conf contains

script "/var/etc/"; # we'd like nameservers and RTSOLD to do all the work

however when dhcp6c attempts to execute the script it fails with:

script "/var/etc/" cannot be executed safely

The issue also appears to occur with "Do not wait for a RA" is not selected, however with a different script error:

script "/var/etc/" cannot be executed safely
Actions #1

Updated by Marcos M 2 months ago

The checks done for this are
  • no setuid
    • setuid'ed execution not allowed
    • lstat failed
  • the file must be owned by the running uid
    • has invalid owner uid
    • is an invalid file type

Try running

chmod u+s /var/etc/
chmod u+s /var/etc/

then test again.

reference wide-dhcpv6 common.c:

    const char *path;
    struct stat s;
    uid_t myuid;

    /* no setuid */
    if (getuid() != geteuid()) {
        dprintf(LOG_NOTICE, FNAME,
            "setuid'ed execution not allowed");
        return (-1);

    if (lstat(path, &s) != 0) {
        dprintf(LOG_NOTICE, FNAME, "lstat failed: %s",
        return (-1);

    /* the file must be owned by the running uid */
    myuid = getuid();
    if (s.st_uid != myuid) {
        dprintf(LOG_NOTICE, FNAME, "%s has invalid owner uid", path);
        return (-1);

    switch (s.st_mode & S_IFMT) {
    case S_IFREG:
        dprintf(LOG_NOTICE, FNAME, "%s is an invalid file type 0x%o",
            path, (s.st_mode & S_IFMT));
        return (-1);

    return (0);

Actions #2

Updated by Marcos M 2 months ago

  • File dhcp6_setuid.diff added
Actions #3

Updated by Denny Page 2 months ago

Setuid on a shell script? That doesn't seem appropriate. And I don't think that lines up with the checks.

The checks are:

1. the effective uid of dhcp6c must be the same as the real id (i.e. the process cannot be suid).
2. dhcp6 must be able to lstat the script (the path must be accessible).
3. the script must be owned by the owner of the process.
4. the script must be a regular file.

So, which of these checks would be failing? The only one I can think of is checks 2 or 4, because the file doesn't actually exist at the time that dhcp6c goes to access it.

The scripts are removed and rewritten at each boot. I am thinking that there is a race condition in creation of the scripts vs the dhcp6c process starting.

For checks 1 and 3, I don't see how that would be an issue as the process is run by root and the scripts are owned by root.

Actions #4

Updated by Marcos M 2 months ago

You're right, I misread it. It's likely what you're thinking.

Actions #5

Updated by Marcos M 2 months ago

  • File deleted (dhcp6_setuid.diff)
Actions #6

Updated by Jim Pingle 2 months ago

The real question here is why it works most of the time then suddenly fails. I'm guessing something is removing the file. I'm seeing log messages from the /var/etc/ script on a test VM here, so it's definitely being executed properly most of the time on DHCP6 events. I also do see one log message where it failed as described here, but only one compared to the dozens from when it ran successfully. The failure is nowhere near any other log message from dhcp6c, but it was around when I made and applied an interface change where I disabled DHCP6 on the WAN when testing something else. I re-enabled it and rebooted a short time later. I'm not seeing it at boot, just that one single time in the log (that goes back 10+ days) when I disabled DHCP6.

The code in the dhcp6c source should be logging an error about why it's failing, but it isn't. I already have the option set to start dhcp6c in debug mode (System > Advanced, Networking tab), so it should have logged even more. So I'm still leaning toward it being a timing issue where the script gets removed before dhcp6c shuts down at some point.

If you just get the message once at boot or when applying changes, and not continually in the log every half hour or so on DHCP6 events, it's probably not worth worrying about.

Actions #7

Updated by Marcos M 2 months ago

I get it once every time after saving/applying WAN interface. When I looked at the code, the files get created before the process starts, so I also suspected it was on exit instead. I was not getting the extra debug either.


Also available in: Atom PDF