Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
Improve this question
I am using some online tutorials to learn the terminal in Unix systems.
Apparently root has full permissions everywhere, but it is inconvenient to su to root, do what you need to do, and then exit back to your normal username.
sudo apparently circumvents this, but I have some questions.
When you use sudo, it doesn't ask you for root's password, it asks for your password.
So what stops you from just sudo'ing everything and mimicking the same functionality of having logged directly into root using the root password?
The purpose of sudo is to allow certain users to run certain programs in certain ways, all of which can be controlled by the /etc/sudoers file and/or files in /etc/sudoers.d. And it logs those uses. So, a system operator, for example, can take backups, or a more senior admin can kill runaway processes, but neither of them gets the complete, unlimited access that su would give them.
When you use sudo, it doesn't ask you for root's password, it asks
for your password.
You must have recently authenticated. This could easily change this so that it authenticates you everytime:
sudo visudo
# that will open /etc/sudoers in vi/vim
# type the following to search the file:
/Defaults
# hit n to go to next result
# Find line that says:
Defaults env_reset
# and change it to:
Defaults env_reset,timestamp_timeout=0
# 0 is time in minutes
You could also use nano /etc/sudoers if you are more comfortable with nano I would recommend looking into vim though. The difference between nano and vim is like the difference between microsoft notepad and sublime/caret.
# Vim cheat sheet for this tutorial
i # insert mode
ESC # exit insert mode (and other modes)
:wq # write changes (w) quit (q)
# a little more advanced:
:%s/search/replace/gc
# replace all instances of search and ask for confirmation:
http://vim.wikia.com/wiki/Search_and_replace
So what stops you from just sudo'ing everything and mimicking the same
functionality of having logged directly into root using the root
password?
Great question! You are apparently part of the sudoers group. Most distros (Distributions of linux\unix) have this group as wheel. Check out usermod to change this for users.
You can confirm the group name in /etc/sudoers :
## Allows people in group wheel to run all commands
%wheel ALL=(ALL) ALL
## Same thing without a password
# %wheel ALL=(ALL) NOPASSWD: ALL
# ^^^ ENSURE THAT THIS IS COMMENTED OUT (or not present) ^^^
Not giving a user sudo access would prevent this.
This is also a great thing:
Everybody and their brother has a root account on their system a lot of script kiddies try to brute force root accounts as well as other common usernames like postgres. It is in your best interest to lock down the root account mitigating ssh brut force attacks. This can be done with passwd -l (RAN AS ROOT).
By having a sudo user you can still do admin tasks like installing software and creating new users.
Apparently root has full permissions everywhere, but it is
inconvenient to su to root, do what you need to do, and then su back
to your normal username.
If you are going to do extended tasks as root I would recommend:
sudo -i
# do whatever you need to do
^D
# CTRL+D This will terminate your current shell and take you back
# to your previous shell whereas su root and su username will take
# you two shells away from your initial session. This probably won't
# effect you besides MAYBE session history (I am not sure about that).
As always be careful because you can really mess up your system as a super user.
As for your title question:
Difference between superuser and root
Ubuntu99 does a great job of summing this up:
https://askubuntu.com/a/592838/212470
The root user is a build in user with administrative privillages in this application. root is the super user for the system, meaning that it has unlimited access to the files.
The root user has following additional role:
To create multiple administrator of an application and message them.
root user can restrict and manage admin users access and their privillages.
Related
I want to give one particular user read access to a file on a unix machine. I am not root so I guess I can not do chown.
I tried searching for something that uses chmod, but there it looks like I can't specify a particular user, only a one-self, group, or all.
I guess this was asked before already, but I couldn't find anything.
Generally when you want more fine-grained permissions in Linux, you should use Access Control Lists. The Arch Wiki has a good guide on how to set it up.
Once set up, you can define more complex rules for modifying the access control policies for your mounted filesystem.
You can set these rules with commands that look like: setfacl -m "u:johny:r-x" abc.
This says "Give (user) Johny read and execute permissions to the file/directory specified by the path abc".
You would then also be able to see the permissions for a filesystem object using getfacl
root#testvm:/var/tmp# getfacl appdir/
# file: appdir/
# owner: root
# group: appgroup
user::rwx
group::rwx
group:testusers:r--
mask::rwx
other::r-x
In this example you can see the default for any user/group which is not (in) the testusers group, can read, write, or execute the directory. But testusers can only read.
The traditional, Unix way is, as you suggest, to chown the file and set permissions that way.
You might also be able to use access control lists (ACLs). Have a look for the getfacl and setfacl commands (link). The bad news is that ACLs are not always enabled and the default OS install doesn't always include the commands, which doesn't help you if you don't have root.
I installed cloud-in-a-box/fastrack of Eucalyptus and am able to create instance and log into it. But when trying sudo, sudo su - or login in as root I'm asked for a password. I'm not sure what the password might be. Does anyone know what the default password for the Image is?
I think this is how the image is designed. It uses the cloud-user account only and has no root access, nor does it allow sudo.
There are other starter images available that can be "installed" that have sudo as root enabled. In those cases you simply issue
sudo su -
and you become root.
To see what is easily available use:
eustore-describe-images
As a note, some of the other starter images have different accounts (not cloud-user), such as ec2-user. If you don't know which account to use simply try to ssh into the instance as root and it will usually get a message back telling you:
Please login as the user "ec2-user" rather than the user "root".
I am not sure if there is a password on the root account in that image. Regardless, the recommended way to log into instances is by creating an SSH key (euca-create-keypair KEYNAME >KEYNAME.pem), specifying it when running an instance (euca-run-instance -k KEYNAME), and then logging in using the key generated (ssh -i KEYNAME.pem root#INSTANCE-IP). You'll probably have to change the permissions on that .pem file before SSH will allows you to use it (chmod 0600 KEYNAME.pem). The instance obtains the public portion of the key from the cloud at boot time and adds it to the authorized_keys file.
On a RedHat 6 server, a third party application requires to be root to run and needs access to sqlplus. I have a running database, I can run sqlplus as user 'oracle'. When logged in as user root, 'sqlplus usr/pwd#dbname' works as expected. The trouble is that this agent needs to run sqlplus with no parameters and it always returns ORA-12546: TNS:permission denied.
I've read a dozen times that enabling root to launch Oracle is a security issue but I really have no other choice.
Running Oracle 11.2.0.1.0.
Any help will be much appreciated as I've googled for 2 days with no success.
From the documentation, ORA_12546 is:
ORA-12546: TNS:permission denied
Cause: User has insufficient privileges to perform the requested operation.
Action: Acquire necessary privileges and try again.
Which isn't entirely helpful, but various forum and blog posts (way too many to link to, Googling for the error shows a lot of similar advice) mention permissions on a particular part of the installation, $ORACLE_HOME/bin/oracle, which is a crucial and central part of most of the services.
Normally the permissions on that file would be -rws-r-s--x, with the file owned by oracle:dba, and this error can occur when the word-writable flag - the final x in that pattern - is not set. Anyone in the dba group will still be able to execute it, but those outside will not.
Your listener seems to be fine as you can connect remotely, by specifying #dbname in the connect string. The listener runs as oracle (usually, could be grid with HA, RAC or ASM) so it is in the dba group and can happily hand-off connections to an instance of the oracle executable.
When you connect without going via the listener, you have to be able to execute that file yourself. It appears that root cannot execute it (or possibly some other file, but this is usually the culprit, apparently), which implies the world-writable bit is indeed not set.
As far as I can see you have three options:
set the world-writable bit, with chmod o+x $ORACLE_HOME/bin/oracle; but that opens up the permissions for everyone, and presumably they've been restricted for a reason;
add root to the dba group, via usermod or in the /etc/group; which potentially weakens security as well;
use SQL*Net even when you don't specify #dbname in the connect string, by adding export TWO_TASK=dbname to the root environment.
You said you don't have this problem on another server, and that the file permissions are the same; in which case root might be in the dba group on that box. But I think the third option seems the simplest and safest. There is a fourth option I suppose, to install a separate instant client, but you'd have to set TWO_TASK anyway and go over SQL*Net, and you've already ruled that out.
I won't dwell on whether it's a good idea to run sqlplus (or indeed the application that needs it) as root, but will just mention that you'd could potentially have a script or function called sqlplus that switches to a less privileged account via su to run the real executable, and that might be transparent to the application. Unless you switch to the oracle account though, which is also not a good idea, you'd have the same permission issue and options.
In my app I ask users to register using a unique name. The app creates a directory for them with that name that they then can work with, saving files, etc.
I hadn't really thought about screening for other than alpha-numeric for the name. However, I ran across a thread somewhere than said to make sure not to create directory names that match a unix command name.
Is this a legitimate risk? If so, how might one programmatically screen for such an occurrence? I'm also curious how such a scenario might play out to illustrate the problem (exploit?). That last part is academic interest only, of course.
Generally, it doesn't matter(has no obvious security risk). Most softwares, for example shell, search a unix command based on some enviroment variables(like PATH). So even if your created directory matches a unix command like "cd", it can only be used as a parameter to other unix command, like cd cd.
However, if another application search the unix command based on other approaches like searching some directories, it may lead to security breaches.
The only way I can think of that being a risk is if you're going to turn around and process those user names through command-line functions. You would want to be careful to escape the user names anywhere that they could be interpreted as a command...though off the top of my head, with strictly alphanumeric user names, you'd have to go to a lot of trouble to run into such a risk.
If you decided anyway that you wanted to ensure that the username didn't match an application on the path of the creating process, you could shell out from whatever your app environment is, and evaluate the result of which $prospectiveUsername. If it returns anything other than an empty string, you know that the username is an application on the process's path.
NOTE: In the above scenario, make sure you sanitize the username before calling out to the shell command. Otherwise, you do run security risks, if e.g. the user decides to enter her username as "janedoe; rm -rf /".
I have a program that is going to take a password as input and then do a shell execute to perform a "su" (switch user) command in UNIX. However, I don't know how to pass the password variable to the UNIX su command. The language I have to use for this is pretty limited (UniBasic).
Any ideas?
Well, the best way to do that would be a setuid-root binary that ask for the password then execute whatever command is needed but it requires knowledge you say not to possess. I'd advise in looking at sudo(1) instead.
You could ssh to localhost as another user to execute whatever command you want. Or, use sudo and edit /etc/sudoers such that sudo does not ask for a password. However, there could be security implications.
EDIT: Please let me know why when you vote it down. My answer may not be perfect but at least it works. I do that myself for some licensed software that can only be run under a weird user name.
You do not want to specify the password as a command-line argument. Not so much because of #unwind's answer (scripts could be made private) but because if someone runs a list of processes, you could see the command argument and hence the password in question.
The version of su I have on my Linux server does not support such an option. I checked sudo, but it doesn't either. They want to do the prompting themselves, to ensure it's done in a safe manner and (I guess) to discourage people from putting passwords verbatim in scripts and so on.
You could also look at the 'expect' utility that was designed to script complex user inputs into a programs that weren't flexible enough to receive this input from places other than stdin.