Bug #13237
opendhcp6c script cannot be executed safely
0%
Description
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/dhcp6c_wan_dhcp6withoutra_script.sh"; # 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/dhcp6c_wan_dhcp6withoutra_script.sh" 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/dhcp6c_wan_script.sh" cannot be executed safely
Updated by Marcos M over 2 years ago
- 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/dhcp6c_wan_dhcp6withoutra_script.sh chmod u+s /var/etc/dhcp6c_wan_script.sh
then test again.
reference wide-dhcpv6 common.c
:
int safefile(path) 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", strerror(errno)); 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: break; default: dprintf(LOG_NOTICE, FNAME, "%s is an invalid file type 0x%o", path, (s.st_mode & S_IFMT)); return (-1); } return (0); }
Updated by Denny Page over 2 years 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.
Updated by Marcos M over 2 years ago
You're right, I misread it. It's likely what you're thinking.
Updated by Jim Pingle over 2 years 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/dhcp6c_wan_script.sh
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.
Updated by Marcos M over 2 years 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.
Updated by Denny Page 7 months ago
I ran across this again in 24.03 when applying a save to the WAN interface.
May 4 09:07:15 fw dhcp6c[25294]: exit without release May 4 09:07:15 fw dhcp6c[25294]: Bypassing address release because of -n flag May 4 09:07:15 fw dhcp6c[25294]: remove an address XXXXXX/128 on igc3 May 4 09:07:15 fw dhcp6c[25294]: Bypassing address release because of -n flag May 4 09:07:15 fw dhcp6c[25294]: remove an address XXXXXX/64 on ix0 May 4 09:07:15 fw dhcp6c[85222]: lstat failed: No such file or directory May 4 09:07:15 fw dhcp6c[85222]: script "/var/etc/dhcp6c_wan_dhcp6withoutra_script.sh" cannot be executed safely May 4 09:07:15 fw dhcp6c[25294]: exiting
It appears that the script has already been removed prior to dhcp6c calling it.
In 24.03, I see this consistently when doing "Apply Changes" following save of the WAN interface. However, as before, I do not see the issue when rebooting pfSense.