Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I got confused with setuid concept. What I have understood is that if setuid set on any file.Anybody run(execute) it, it will run as it has ran by its owner.
Is it my concept is correct.
If not please make me explain from example other than passwd.
If it is correct than check my example that I performed.
I have created a file lsscript.sh with permission 4700, means owner has full permission with setuid bit.
now I switched user and tried to run lsscript.sh. But its shows permission denied.
you cannot use setuid bits on scripts, but on binaries. Scripts are not standalone executables but there are interpreters (like bash/perl/whatever) to interpret/execute/run them.
Therefore setuid on the script (which is a plain text file) is meaningless.
You ought to set it on the binary, but I do not really suggest you to set setuid on bash or similar (but you can make a local copy of it and try that one).
I have created a file lsscript.sh with permission 4700, means owner has full permission with setuid bit.
now I switched user and tried to run lsscript.sh. But its shows permission denied.
Why? It should have run with owner permission.
The 4700 says only the owner can run the script. The 00 for group and others is what gave "permission denied." To try what you want you'd have to set permission to 4750 (if the other user is in the same group) or 4755 so any other user can run the script. Note in both cases, you wouldn't be allowing others to change the script, only read and execute it.
That said, pan64 may be right about when to use setuid. Personally, I have only used it on directories to force the files within them to be owned by the user (or group), and not on scripts or binaries.
you cannot use setuid bits on scripts, but on binaries. Scripts are not standalone executables but there are interpreters (like bash/perl/whatever) to interpret/execute/run them.
Therefore setuid on the script (which is a plain text file) is meaningless.
You ought to set it on the binary, but I do not really suggest you to set setuid on bash or similar (but you can make a local copy of it and try that one).
You can make setuid Perl and Python scripts, just apparently not shell scripts. At least you used to, but perhaps that has changed. You can always write a simple C wrapper around anything and that will be able to get the job done.
EDIT: Yeah, this seems to have changed in most systems and they won't even let Perl do setuid scripts, so you need to write a simple C wrapper that's setuid to launch the script while it is root.
The main reason is that some things like system utilities need to run as root to get access to certain kernel information, certain files, or perform certain tasks.
Really simple programs to understand the logic behind it would be su or sudo.
In order to be able to switch to root or run another program as root, the program that does it obviously has to be running as root to begin with. So su runs as root, asks for your password, then if it authenticates, it changes your userid to root (or any other user) and executes another shell, then you have a # prompt instead of a $ prompt. Same idea with sudo, but you don't get a root shell, you have run each program separately by using sudo with each one
I was always told that the suid bit is not honoured on scripts as a security precaution, to prevent "script kiddies" running malware on your system. Writing and compiling a proper program is beyond the capacity of most of these idiots.
It can't just be because scripts are text, since they can be made executable and most text files can't.
This is exactly what I meant. the setuid on text file (script) itself is ignored, not used. You need to have a setuid binary (either interpreter or shebang or similar) to do that.
The 4700 says only the owner can run the script. The 00 for group and others is what gave "permission denied." To try what you want you'd have to set permission to 4750 (if the other user is in the same group) or 4755 so any other user can run the script. Note in both cases, you wouldn't be allowing others to change the script, only read and execute it.
That said, pan64 may be right about when to use setuid. Personally, I have only used it on directories to force the files within them to be owned by the user (or group), and not on scripts or binaries.
Thats what group and other dont have access to run script, so only I tried to setuid as its say it will run as it has run by owner and owner has permission to run it.
And if I give 755 permission to script than why I need to set setuid to it. It already got access to run script.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.