The whole point of set-UID code (a.out format executables, executable shell scripts or, on most systems a script to be run by the interpreter named by a #! line at the start of a file) is that it runs with the permissions needed to access (read, write, or execute) anything that someone who had logged in as the owner of that file could access.

So, if you have personal files that are mode 700 (readable, writeable, and executable only by you) and you let someone run code that you own with the set-UID bit set, the user running that code can read, write, and execute those personal files if that code accepts names of files from the user causing the code to access those files.

For example, let's assume you have a file /Users/login/private containing:

Code:

login's password: xxx
login's bank and account number: xxx

set up such that ls -lfor that file produces:

Code:

-rw-------  1 login  staff  59 Mar 30 21:42 /Users/login/private

And, assume you have a shell script /Users/login/bin/pp that contains:

Code:

#!/bin/ksh
cat /Users/login/private

that is readable and executable by anyone:

Code:

-rwxr-xr-x  1 login  staff  36 Mar 30 21:46 /Users/login/pp

Then when the user named login runs this script, (s)he will see the contents of the file private displayed on the screen. But, if anyone else runs this script, they will see something like:

Code:

cat: /Users/login/private: Permission denied

But, if you make this script set-UID:

Code:

-rwsr-xr-x  1 login  staff  36 Mar 30 21:46 /Users/login/pp

then when any user runs this script they will see the contents of the file.

Setting up a secure set-UID shell script is not something you should do unless you fully understand all of the ways that the script could be spoofed into performing undesired things to your personal data. If you look at the EXAMPLES section of the POSIX command utility in the Man Pages section of this forum, you can get an overview of some of the issues that need to be considered when writing set-UID shell scripts.