You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CORC intentionally drop privileges to create log files even when run as root or sudoing. This is a problem when creating and writing to log requires these privileges: typically in VM with shared folder.
Actual Behavior
In VM, within a shared folder, requires specific user and group rights.
Works fine when run as user (not sudoing).
Fail with impossible log creation (spdlog exception) when run with sudo:
terminate called after throwing an instance of 'spdlog::spdlog_ex'
what(): Failed opening file logs/CORC.log for writing: Permission denied
Aborted
Possible Fix
One idea would be to get actual user id and gid when sudoing but this is not sufficient and still fail:
/* Privileges management */
static uid_t uid, gid; //Saved uid and gid
void save_privileges() {
uid = getuid();
gid = getgid();
}
int drop_privileges() {
if (uid == 0) {
//If sudoing and not directly root (likely): use sudoer uid to create log files
if(getenv("SUDO_UID")) {
//Drop group privileges first
if( setegid(atoi(getenv("SUDO_GID")))<0 || seteuid(atoi(getenv("SUDO_UID")))<0 ) {
CO_errExit("Failed to drop privileges.");
return -1;
}
}
else {
//Drop group privileges first
if( setegid(1000)<0 || seteuid(1000)<0 ) {
CO_errExit("Failed to drop privileges.");
return -1;
}
}
}
return 0;
}
int restore_privileges() {
if( setreuid(uid, gid)<0 ) {
CO_errExit("Failed to restore privileges.");
return -1;
}
return 0;
}
/* --------------------- */
=> This still produces the same error.
Workaround can be to not drop privileges in any cases and so create log files only accessible by root.
The text was updated successfully, but these errors were encountered:
Description
CORC intentionally drop privileges to create log files even when run as root or sudoing. This is a problem when creating and writing to log requires these privileges: typically in VM with shared folder.
Actual Behavior
In VM, within a shared folder, requires specific user and group rights.
Works fine when run as user (not sudoing).
Fail with impossible log creation (spdlog exception) when run with sudo:
Possible Fix
One idea would be to get actual user id and gid when sudoing but this is not sufficient and still fail:
=> This still produces the same error.
Workaround can be to not drop privileges in any cases and so create log files only accessible by root.
The text was updated successfully, but these errors were encountered: