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.
Related
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.
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.
Is there anyway to deny access to certain commands and executables while in a certain folder?
Specifically, I am trying to deny the access of pwd while in certain folders, so that users that access the folder via a symlink cannot see where in the file hierarchy they are (in order to prevent some security issues), but are able to use retain use everywhere else.
You can move pwd to another directory and make a script called pwd like this:
provided new location of real pwd is /path/to/movedpwd:
#!/bin/sh
if test /path/to/movedpwd = UNWANTED_DIR
then echo "Forbidden dir!"
else pwd fi
Then make it executable-only so that the users cannot find the real pwd.
I have a script (Joomla) that creates files and directories on the server. The problem is that it creates them under owner 99 99 (nobody) and after I can't delete or modify them by FTP without the help of the server admin.
I think that is move_uploaded_file function of php.
Is there any solution of this problem by the WHM or by the server admin? Can I modify the default owner in ftp?
What happens is the HTTP server is ran by a user called "nobody", and your FTP user is another one. When the upload occurs, the HTTP server creates the file under its username, and your FTP user has no permission to write (or delete) these files.
The easiest way to fix this (but not really secure) is to add both users in a same group, and change the file permissions to allow users of the same group to read/write on these files.
Your admin should take care of it, but you'll have to call chmod() to change the permissions of your uploaded files.
Explaining it better:
The linux/unix file permissions are composed by permissions of user (u), group (g) and others (o).
I'll only cover 3 types of file permisions here, which are read (r), write (w) and execute (x). So, you end up having something like this:
-rw-rw---x 1 jweyrich staff 12288 Oct 24 00:22 avatar.png
The first rw- is the permission (read/write) of the USER that owns the file (jweyrich).
The second rw- is the permission (read/write) of the GROUP that owns the file (staff).
The --x at the end are the permissions (execute) of the OTHERS users..
Your PHP scripts run as "nobody" user (and by, let's say, "nobody" group), so every file you create from your PHP will be owned by the "nobody" user (and his group). A user can be part of one or more groups.
To solve the permission problem, your FTP user and the "nobody" must be in a common group, let's say the admin put your user in the "nobody".
Once they're in the same group, your PHP script has to give "rw" (read/write) permissions to the "nobody" group members. To do so:
chmod("path_to_your_file", 0770);
The 0770 is equivalent to "u+rwx,g+rwx,o-rwx" , which I explain here:
u+rwx = for user (owner, which is "nobody"), give read/write/execute permissions
u+rwx = for group (which is also "nobody"), give read/write/execute permissions
o-rxw = for others, remove the read/write/execute permissions
After that, your FTP user, which is now part of the "nobody" group, will have read//write access to the uploaded files, and thus can also delete the files. It would look like this:
-rwxrwx--- 1 nobody nobody 12288 Oct 24 00:22 avatar.png
It's not the ideal introduction to unix file permissions, but I hope this helps.
The user that PHP runs under - nobody - is set by the system administrator. There's nothing you can do about that.
You can try chown() to change the file's owner if you know the FTP user's ID. Usually though, you will not be allowed to do this from within PHP.
Depending on the group situation on the server, it could be that if you use chmod to change the file's access rights after the file has been uploaded, the FTP account can access the file:
Try this first:
chmod($uploaded_file, 0660); // owner+group read+write
If that doesn't work, try this:
chmod($uploaded_file, 0666); // global read+write
one of these should make the file usable by the FTP account.
The 0666 is highly discouraged because other users on the server could write into your files, but in some configurations, it's the only way to get going.