I am trying to write a shell script to mount loop device, and I am assigning this script with a sticky bit to execute as uid(root).(this is for other users on server) The problem is I can't seem to run 'mount' command without using sudo in front of it. When I am in root account, I can run 'mount' command without any issue, so I thought by setting script with rws-r_x-r_x would do it.
Am I misunderstanding the concept of using sticky bit? or is there any other way?
The server is running under Ubuntu 10.04
You mean the setuid bit, not the sticky one. The kernel doesn't honor the setuid bit on scripts. See this post for a thorough description, here's a summary: the gist is that suid on a script is insecure.* The kernel starts reading the script to execute it, but it sees the #!/path/to/interpreter and figures out that it needs to be interpreted. It then cancels "executing" the script directly and calls the specified interpreter, passing the script name as the first argument (and all subsequent arguments in order after that). The reason setting UID is insecure in this instance is that an attacker could potentially change the script to be executed between the kernel setting the new UID and the interpreter reading the file.
*: The other post mentioned that perl handles its scripts in such a way that they can be suid.
As for the actual mounting problem at hand, add a line to /etc/fstab/ and include the user option.
Related
Is there a way for one process (such as an executable or bash script) to elevate the privileges of another, running, process? e.g. If I have a program running as normal user user, is it possible for another process, running as root to elevate the privileges of the first as if it had been run as root originally?
I have seen exploits modify the credential struct of a process to perform this, but I'm not sure if there's a way to do this more legitimately.
Looking further into this, it appears that there is no way to do this without installing a kernel module; essentially a rootkit. The kind of thing I want is demonstrated here.
No, these properties of a process cannot be altered after it starts.
No. The only way to elevate a process’s privileges is by execing a setuid binary (such as /usr/bin/sudo); you can’t do it to an already running process.
You can, however, ask sudo to copy a file to a temporary path, launch your editor with your own privileges on the temporary path, and then copy the result back in place as root:
sudo -e filename
This is possible, but only at Ring 0, using the commit_creds(prepare_creds(0)), which will update the task struct associated with the userland process, setting UID/GUID to 0. This is only possible with code already running in Ring 0, such as a Kernel module/rootkit or kernel exploit. An example of how this may be done is here.
You could start a new process using sudo, but starting a new instance with higher permissions will always result in a new process being created.
It's not possible to grant additional permissions to an already running process.
This is a linux related problem. I have searched around but did not get a good explanation.
It seems to me that both file configure the setup when I log in, but is there any difference? I notice that there seems to be "some rule" in deciding what should go into two different files. For example, if I need to add a specific search path to $PATH, I should do it in ~/.bashrc. But if I decide to change some system setting, like
/sys/class/backlight
or
/sys/devices/cpu/cpu#/online
then I have to do this in /etc/rc.local, otherwise it will not work.
Is it because these configurations can not differ between users?
Thanks.
The difference is in when they are run and who they're running as when run i.e. rc.local is run on a change of run level and it runs as root. bashrc is bash specific and run on a non login shell as a particular user.
You can find a good explanation of rc.local here
The script /etc/rc.local is for use by the system administrator. It is
traditionally executed after all the normal system services are
started, at the end of the process of switching to a multiuser
runlevel. You might use it to start a custom service, for example a
server that's installed in /usr/local. Most installations don't need
/etc/rc.local, it's provided for the minority of cases where it's
needed.
and you can find what you need about bashrc
man bash
When an interactive shell that is not a login shell is started, bash
reads and executes commands from ~/.bashrc, if that
file exists. This may be inhibited by using the --norc option.
The --rcfile file option will force bash to read and
execute commands from file instead of ~/.bashrc.
There's more info on bashrc in this question...
https://superuser.com/questions/49289/what-is-the-bashrc-file
This question was asked by me a month ago, though later I realized that stack overflow is not the best site for this Linux question. Thanks for people who answered this question earlier, but I would like to add some more explanation here.
Basically there are (at least) three stages where a user may change system environment in Linux:
when the system boots; This stage is most appropriate if we fancy permanent system setting, and should be made via /etc/.... For example, in my original question, the backlight, as well as on-line/off-line management of some CPUs can be set in this way, and /etc/rc.local is the right shell script I should edit. By "permanent", it means that this update will affect all users using the system.
when a user logs in; This stage is most appropriate if a user only wants to change his personal Linux environment. Therefore, files under ~/ (or HOME) should be the right place to look for. For example, ~/.profile (historically referred to as ./bash_profile or ~/bash_login) is a shell script run at login time. ~/pam_environment is not a shell script, but useful for setting environmental variables (see Ubunte-official-wiki-environmental_variables for more information).
when a user starts a bash shell; This stage is more restricted, as it only has effects inside a bash shell (as well as its child processes), hence does not affect GUI environment. So if a user is doing most of his job from a shell, then this is an appropriate stage to go for. The shell script related to this stage is ~/.bashrc. For example, environmental variables PATH can be changed here.
Hopefully this summary is more intuitive than technical.
.bashrc runs for each bash session started (i.e. every time you open a shell). It sounds as though you're talking of .bashrc as if it were .bash_profile which is run once per login.
Depending on what kind of setup you're running the rc.local is a legacy construct but, traditionally it was run on the last run level during start up. You can see this link for other related posts talking about rc.local.
If you're on a system running systemd this is usually included by default in the systemd package systemd-backlight.service.
How to invoke a linux command prompt from html page using shell scripting...?
For exp:
I am new to the group and am looking for some quick advice/help in writing a cgi script or scripts. I unfortunately don't have the time/resources to visit a course or read tons of documentations or books.
I have written several shell scripts in ksh bash etc. to perform various tasks on several solaris and linux servers. Some of these scripts take input from the user which is read in as shell positional parameters. I am now required to make these scripts available via a web interface. I need a way to get input from the user and pass that input to my shell script. The input from the user is short. Usually an ip-address or customer name.
What are your suggestions?
Changing the IP address requires root privileges. Thus a CGI executed by the webserver requires these rights.
So either you run the webserver as root (which is really bad) or you need to develop some custom intermediate scripts that invoke the scripts you already have which have the suid bit.
The tutorial proposed by Joachim Pileborg can be good to develop the intermediate script without having to learn a new language such as php.
I have a question closely related to this thread:
Best practice to run Linux service as a different user
but I need the solution to work in "every" Linux distribution.
I would like to run a program as a non root user from a script. This way, when init.d starts up the services at boot time as root, the script launches the process as the non-root user I specify. Of course the solution shouldn't prompt for a password.
I think this is the normal/correct procedure when deploying applications.
How could I do that?
Thanks a lot
A good way would be to drop privileges from your actual program. Then just pass that user as a parameter. Inside you can handle it in a very standard way (setuid())
Otherwise su -c 'your command' different_user will work just fine on any linux. (as long as different_user exists)
There are two ways:
sudo command - you need to add the original user to /etc/sudoers with such entry that the program can be run without (NOPASSWD)
seteuid() system call (if you can modify the program)
If you are root, you can also use su (see #cnicutar's answer for details)
I have a webserver which will frequently spawn a latex interpreter (written in python). This interpreter lives inside a chroot jail made using jailkit so it has to be started as root.
I don't want the server to run as root and I can't setuid the bash script. I could write a setuid c program that calls the script but I'm pretty sure that leads to big security holes.
The best I have come up with so far is running a separate webserver as root whose sole job is spawning interpreter processes.
What is the right way to do this?
Your best bet is to create a very small script which simply set the environment and calls the latex interpreter and make that script SUID root.
This is best because:
The least amount of time is spent as root
Just a single script needs to be SUID
Small script == smaller chance to do something wrong
BASH is pretty safe to use as root while running a whole web server is not.