Return to Answer

Saving root password in any file is tantamount to shooting yourself in the foot. Too high risk.

Best approach is to have a script for the dedicated task and assign that with the setuid-bit permission (ex. chmod 4755) to run as root and with group permissions to a group dedicated for the task. That script would not assign write privileges to anyone but root, who would be the script owner.

Then create a dedicated user ID to perform that task in a dedicated space (examples are cron, sync, daemon, lp, mail, sys, etc). Then have that user run the task when required. That approach makes it a configured facility with known privilege to perform a restricted task. That is the cleanest approach.

The whole point of sudo is to force an interractive verification that the user attempting to gain superuser privileges is authentic and legitimate because they are trying to "circumvent" pre-defined processes. It isn't meant to be easy.

Small script to demonstrate setuid function is active:

#!/bin/sh

BASE=`basename "$0" ".sh" `
TEST="${BASE}.testor"

touch "${TEST}"

Snapshot of that script in action:

Saving root password in any file is tantamount to shooting yourself in the foot. Too high risk.

Best approach is to have a script for the dedicated task and assign that with the setuid-bit permission (ex. chmod 4755) to run as root and with group permissions to a group dedicated for the task. That script would not assign write privileges to anyone but root, who would be the script owner.

Then create a dedicated user ID to perform that task in a dedicated space (examples are cron, sync, daemon, lp, mail, sys, etc). Then have that user run the task when required. That approach makes it a configured facility with known privilege to perform a restricted task. That is the cleanest approach.

The whole point of sudo is to force an interractive verification that the user attempting to gain superuser privileges is authentic and legitimate because they are trying to "circumvent" pre-defined processes. It isn't meant to be easy.

It seems setuid has been disabled without attempts to use it flagging its inactive status. That is not Kosher !!!

Small script to demonstrate setuid function is NOT active:

#!/bin/sh

BASE=`basename "$0" ".sh" `
TEST="${BASE}.testor"

touch "${TEST}"

Snapshot of that script in action:

Saving root password in any file is tantamount to shooting yourself in the foot. Too high risk.

Best approach is to have a script for the dedicated task and assign that with the setuid-bit permission (ex. chmod 4755) to run as root and with group permissions to a group dedicated for the task. That script would not assign write privileges to anyone but root, who would be the script owner.

Then create a dedicated user ID to perform that task in a dedicated space (examples are cron, sync, daemon, lp, mail, sys, etc). Then have that user run the task when required. That approach makes it a configured facility with known privilege to perform a restricted task. That is the cleanest approach.

The whole point of sudo is to force an interractive verification that the user attempting to gain superuser privileges is authentic and legitimate because they are trying to "circumvent" pre-defined processes. It isn't meant to be easy.

Saving root password in any file is tantamount to shooting yourself in the foot. Too high risk.

Best approach is to have a script for the dedicated task and assign that with the setuid-bit permission (ex. chmod 4755) to run as root and with group permissions to a group dedicated for the task. That script would not assign write privileges to anyone but root, who would be the script owner.

Then create a dedicated user ID to perform that task in a dedicated space (examples are cron, sync, daemon, lp, mail, sys, etc). Then have that user run the task when required. That approach makes it a configured facility with known privilege to perform a restricted task. That is the cleanest approach.

The whole point of sudo is to force an interractive verification that the user attempting to gain superuser privileges is authentic and legitimate because they are trying to "circumvent" pre-defined processes. It isn't meant to be easy.

Small script to demonstrate setuid function is active:

#!/bin/sh

BASE=`basename "$0" ".sh" `
TEST="${BASE}.testor"

touch "${TEST}"

Snapshot of that script in action:

Saving root password in any file is tantamount to shooting yourself in the foot. Too high risk.

Best approach is to have a script for the dedicated task and assign that with the sticky-bit permission to run as root and with group permissions to a group dedicated for the task. That script would not assign write privileges to anyone but root, who would be the script owner.

Then create a dedicated user ID to perform that task in a dedicated space (examples are cron, sync, daemon, lp, mail, sys, etc). Then have that user run the task when required. That approach makes it a configured facility with known privilege to perform a restricted task. That is the cleanest approach.

The whole point of sudo is to force an interractive verification that the user attempting to gain superuser privileges is authentic and legitimate because they are trying to "circumvent" pre-defined processes. It isn't meant to be easy.

Saving root password in any file is tantamount to shooting yourself in the foot. Too high risk.

Best approach is to have a script for the dedicated task and assign that with the setuid-bit permission (ex. chmod 4755) to run as root and with group permissions to a group dedicated for the task. That script would not assign write privileges to anyone but root, who would be the script owner.

Then create a dedicated user ID to perform that task in a dedicated space (examples are cron, sync, daemon, lp, mail, sys, etc). Then have that user run the task when required. That approach makes it a configured facility with known privilege to perform a restricted task. That is the cleanest approach.

The whole point of sudo is to force an interractive verification that the user attempting to gain superuser privileges is authentic and legitimate because they are trying to "circumvent" pre-defined processes. It isn't meant to be easy.