A couple of comments indirectly related to this question:

• Do you manage the set of users that should access this utility in some centralized database (LDAP, ADAM, NIS+, ...)? If so, it may be worth while to add the group to the sudoers file. By adding the group (and tying it to your central user database), your management becomes much easier, and adding or removing access happens as part of your central operations instead of as a one-off step.
• If you have the password available in the perl script, the user will be able (given sufficient tools) to read the perl script and find the password to the account. Perl scripts (typically) must be readable by the users that are executing them.

And-d-d-d-d.... my “very short, but shoot-you-in-the-head before you have a chance-to-do more-damage to-the-world” response to this, is as follows:   “No, the-hell, you don’t!”

Stop and think about this ... think very hard about this.

Suppose that your Gentle User is not “Alice” or “Bob,” but rather, “Eve.”   Also suppose that Eve’s masquerade is perfect.   You, in actual fact, have no way to know whether whoever-just-showed-up at-your-door wears a White hat (Alice) or a Black one (Eve).

Therefore, you must assume ... Black.   Alice is Eve unless she can prove herself to be otherwise ... and, there is no capability for her to do so.   ... Unless™ this is an intra-net application operating in a context where the “business-relative identity” of the user can, in fact, be assured, to the perfect satisfaction of the Business and of every single one of its Government Auditors.

Ergo, you basically must not seriously-contemplate doing anything at all, no matter what it is, that would presuppose the successful use of sudo, with or without(!!) the sudoers mechanism.   You have no idea who the user actually is.   Therefore, you simply cannot in good conscience design or deploy any sort of application that would “operate as a proxy for” ... “Eve, successfully(!!) pretending to be Alice.”

Not only do you not know that you can issue a sudo command directly, but you also do not know that you can legitimately assume the system-identity of anyone who could, legitimately, pass a sudoers test.   Any competent security-auditor would quite properly reject any hypothesis that you could offer here, because:   “Eve” will succeed is provably capable of succeeding in penetrating any such system ... and the resulting disaster will have your name on it.

Therefore, it is now time to go back to the drawing board.   And, if you do manage to figure-out something that works, I strongly suggest that you get your manager’s vice-president(!) to sign-off on your brainchild first.   (No... This Is Not A Drill.™)   “Is it really that important?”   Uh huh.   Yeah.)

I can't help but notice you didn't say what the "job" was, that you needed to su, or sudo to, to accomplish.

If it's some recurring task. Perhaps there's a better tool to do that job. Such as cron. Which would mean, all you'd need to do is create a CRONJOB.

Frankly; I think that in this case, there are probably better tools already available to accomplish something that, where the need elevate user privileges is required. But if you DO need Perl, you will most certainly NOT want to automate the password-passing part (pre-fill that part).

Best wishes.

--Chris

Well, if you prefer the /etc/suauth way to do things it's up to you, just use su -c "command ..." if you like.

Otherwise it's not a good idea to save clear-text passwords in scripts, and security tools like su or sudo tend to actively resist attempts to feed them passwords from standard input. Maybe a setuid script is what you need but frankly if you ask questions like that you are not ready to write scripts run by a privileged user.

To reiterate, sudo (and sudo -n for CGI scripts) is the way to invoke privileged commands from a script run as regular user. Unlike general-purpose su it can check what user tries to do and limit his activities to safe ones only. However it's not omnipotent so your mileage may vary.