sudo in a bash script

Move the script to the top level of the hard disk or a preinstalled folder only writable by root, such as /private. Next, use a tool such as visudo to edit the sudoers file so that non-admin users can use sudo to execute that script and only that script; the sudo in the script can then be removed, and the line in sudoers can be set so that no password is required to run it. From here, change the permissions on it so that only root is able to edit the script.

(20394)

If all you're doing is trying to change ownership not permission, so long as you have read access to the file, you can change ownership by creating a new file with the exact same properties with cat.

cat file1 > file2

file2 will retain original permissions of file1, but the group will be changed to whichever user runs cat.

Since this changes ownership of the file, at this point you just do:

chmod 777 file2

Which will give you full access to file2.

Hope that helps.

that will confuse things, since your approach creates duplicate files. he just wants to work with existing files. the way for non-admins to chown them properly is to edit the sudoers file as indicated above.

with more detail from the original poster, it may be possible to work out an even more elegant solution.

why do the non-admins need to change ownership to allow another group to use the files? have you tried ACLs to accomplish the same thing? in essence, what's the problem you're trying to solve?

Dear Greg,

The keys are in chmod, chown, & sudo.

Make your scrip owned by root like this:

$ sudo chown root script.sh

There is a secret bit on the access controls called the sticky bit. If an executable is owned by root & has the sticky bit set, the executable runs with root authority. Set the sticky bit like this:

$ sudo chmod 1755 script.sh

Now when the script runs, it runs with root authority.

But you need to be real careful with access control to script.sh. If someone can change script.sh, they have root access to your system. So guard script.sh well.

Best of luck,



Kurt

The instructions regarding changing the file mode weren't set up properly; the number needs to be 4755 instead of 1755 for this purpose. Note that setuid shell scripts are disabled by default in Mac OS X 10.39 and newer; you can use these instructions to turn them back on.

(20462)

Hi Kurt, Greg,
Kurt, this is a rare mistake but you're thinking about the SetUID bit, not the sticky bit. The effect of the sticky bit on files was supposed to be to keep text portions of an executable in memory but the architecture it was designed to optimized is obsolete so I doubt that it has any effect on executable files nowadays. (it still affects directories)

Setting the SetUID bit, 4000, on an executable binary will cause the operating system to execute it as the owner of the executable but that no longer works on scripts since that would be a security hole. However, it is a simple matter to wrap the invocation of the script in a C executable, on which the sticky bit will work. There is a section of the perlsec man page that describes how to do it and even provides the C code. All you have to do is fill in the absolute path to the script, compile it with gcc and set the SetUID bit on the resulting executable.

Greg, I think that editing the sudoers file is the best solution but you should really study the sudoers man page before doing so. Sudo is one of the most flexible authority mechanisms there is but that also means that configuring it can get involved.

As was suggested you can include the path to your script in an entry in the sudoers file and even use the NOPASSWD flag to allow it to be executed without a password being required. However, your users will still have to use sudo. An alternative is to put the individual commands in the sudoers file and to execute them in the script with sudo. Of course you should include the arguments to the commands in the sudoers file as you wouldn't want your users to be able to freely chmod as root.

Edit: I strongly recommend not turning on the effect of the SetUID bit on scripts. It really is a security flaw, as is also described in the perlsec man page.
--
Gary
~~~~
Obstacles are what you see when you take your eyes off your goal.

Try creating a second shell script, and placing the sudo command inside that shell script. The first script can then be called from the second, without the person using the computer needing to type sudo. The second script does not need to be in a protected folder.

(20472)

Dear Gary,

Opps! My mistake:^( This is what happens when I rely on my memory rather than the the computers memory.

Thank you for the correction. At least I had the commands right.

Thank you for the sudo suggestion. I will keep it in my useful unix methods file for future use. It is always good to know the right way to do things.

Best of luck,


Kurt