I created a directory /share and gave chmod 2770 permission and chown root:stock /share.
1) When I create touch a file inside /share, I see the file has rw-rw-r-- and I don't see rwxrws---
2) When I create a directory in /share/data I see the permission as drwxrwsr-x where are the parent directory is drwxrws---
How can I get parent child files and child directories to inherent parent permissions exactly the same.
The setgid bit on a directory makes new files inherit the group from the directory, not its permissions.
The standard way of controlling the bits that get set on the creation of a file is to control the umask (askubuntu) of the creating process, not the file system.
When you create a file or directory
The owner of the new file or directory will be your effective user id (euid). You can change user id beforehand with the su other_user command (which will prompt you for the password of other_user), or sudo su other_user (which will allow you or not, possibly asking for your password, according to the settings in /etc/sudoers*). After creating the file or directory, you can change its owner with sudo chown other_user file_name.
The group of the new file or directory will be your effective group id. You can change your group id with the newgrp other_group command beforehand. If your current directory has other_group as group and its setgid bit is set, your effective group id will be other_group. After creating the file or directory, you can change its group with chgrp other_group file_name. newgrp, chgrp and setgid will work if you are a member of other_group. If you are not, they won’t: a group password mechanism is theoretically still in place, but it was deprecated decades ago and I’ve never seen anybody using it. Of course, you can always sudo chgrp other_group file_name, or even sudo chown other_user:other_group file_name if you want to change both.
The read and write permissions of the new file or directory will depend on your umask, which is normally set by your configuration files at login. The most used umask values are 022 which, for files, will give you -rw-r--r-- and 002 which will give you -rw-rw-r--. The command umask will give you your current value. You can set another value with umask new_value and it will be effective till you change it or exit your shell. Directories will have also all execution permissions set by default, unless you have odd values in umask, which will block the corresponding execution bit. E.g. a umask value of 027 will create files with -rw-r----- and directories with drwxrwx---. Please refer to documentation for a complete explanation. Also, if the parent directory has the setgid bit, the new directory will have it too. There is no way of setting the setuid and sticky bits by default, nor the setgid bit for files.
After the fact, you can always set the permissions you want with the command chmod.
That said, there is no standard command which will do what you want. However, you can easily write bash functions like the following and use them (write them in a file mycreat_functions and source mycreat_functions when needed). This will do for manually created files and directories. For file created by programs, shell redirections and the like, you will still have to correct the permissions manually.
function mymkdir () {
local parentperms
for a in "$#"; do
mkdir "$a"
# This copies all permissions of the parent,
# exactly as they are
parentperms="$(stat -c%a $(dirname "$a"))"
chmod "$parentperms" "$a"
# if I’m root...
if [ $(id -u) = 0 ]; then
chown "$(stat -c%u:%g "$a")" "$a"
fi
done
}
function mytouch () {
local parentperms newperms
for a in "$#"; do
touch "$a"
# This inherits all permissions of the parent,
# but removes the excution and setgid bits, as is
# appropriate for files.
parentperms="$(stat -c%a $(dirname "$a"))"
newperms="$(printf %o $((8#$parentperms & 8#5666)))"
chmod "$newperms" "$a"
# if I’m root...
if [ $(id -u) = 0 ]; then
chown "$(stat -c%u:%g "$a")" "$a"
fi
done
}
Note: Owner, group and permissions are stored in an inode, where there is also other information on how to retrieve the file contents; the directory entry associates the inode with the file name, and ls -i shows the inode numbers of the listed files. When you copy a file, you create a new directory entry and allocate a new inode, so everything mentioned here applies. When you move a file, you create a new directory entry in the new location, but have it point to the old inode, so that owner, group and permissions are effectively untouched. If you want them to change according to the new directory entry’s parent, you have to create a mymv function along the lines of mytouch and mymkdir above.
Related
I am trying to understand the following commands:
mkdir /data 0770 root system
mkdir /data 0770 system system
mkdir /data 0770 system room
https://android.googlesource.com/platform/system/core/+/b4d65399fde02280b718e3b5b5cb1464a885c4b0/rootdir/init.rc
Line 58
mkdir is creating the directory,
/data is path,
0770 giving read write permissions to the directory,
root system I don't know.
The format is
mkdir <path> [mode] [user] [group]
The path defines which directory has to be created. The mode defines the permissions for the directory. The user and group define who is the owner of the directory. The permissions are relative to the user and the group owning the directory. For example, mkdir /data 0770 root system means the /data directory is owned by the user root and the group system. The root user has read/write/execute permissions (because of the first 7) and the same holds for every user that is a member of the system group (because of the second 7). Every other user has no permissions (because of the last 0). The leading 0 has no special meaning in this case, it just signifies the beginning of an octal number.
The commands that can be used in the init.rc are defined here.
You can also inspect the user and group that owns a directory from the command line, using ls -l:
# ls -l
...
drwxrwx--- 45 root system 920 1971-02-01 00:26 data
Since you mentioned security labels: These permissions are unrelated to SE Linux labels. The file permissions are considered Discretionary Access Control (DAC), whereas SE Linux labels are Mandatory Access Control (MAC).
You can inspect the SE Linux label with ls -lZ:
# ls -lZ
...
drwxrwx--x 45 root system u:object_r:system_data_file:s0 920 1971-02-01 00:26 data
So in this case the SE Linux label would be u:object_r:system_data_file:s0. In general, the SE Linux label of a file would not be set dynamically via the init.rc. Rather, the labels are defined statically via the file_contexts file in the SE Linux policy (reference). Newly created files by default inherit the SE Linux label of their parent directory. To apply the label from the policy to a newly created file, the restorecon command can be used, as can be seen e.g. here.
I am trying to giving permission to root user generated file but not able to do this. Can anyone help me how to do this?
I tried:
echo -e 'password'> sudo chmod 777 file.txt
Example:
file.txt rw-r--r-- root
Expected result:
file.txt rwxrwxrwx spate233
First of all, I can't see what you're doing by "echo -e 'password'".
The '>' character means "output redirection", that is, bash will redirect the input of the "echo -e password" command to a file named "sudo" in the directory that you're working. The part "777 file.txt" will be appended to that file(i didn't know this, I just tested it in my PC and that's what happened).
Apart from that: if you want to access a root generated file you have to take into account that root generated files have "root" as owner and "root" as owner group.
If the user that you're trying to give permissions is a sudoer, then you can just operate using "sudo", just like you did in the example.
If it is not, and you want your user to have permissions, it would be enough to set permissions for "other" domain. You can try this:
sudo chmod o+rwx file.txt
This adds all permissions (i.e. rwx) to the other users domain.
However, if you want to give 777 permissions to the file, you just use
sudo chmod 777 file.txt
or also, if you want to use a syntax like the previous one
sudo chmod a+rwx file.txt
If it your desire, then you can also change the owner of the file. Doing this can lead to some security problems, so it is avoided if the file you are dealing with is a system file. I think this is not the case, so you can just do:
sudo chown user:group file
Where user and group are substituted with the new owner and the new group of that file.
I have a directory at
/home/ec2-user/vertica1
and I'm trying to get user dbadmin all privilages in that folder.
I've done chown to dbadmin and chmod 777 on that folder but dbadmin still gets a permission denied error.
If I put sudo in front of the command(I put dbadmi in sudoers), then it works. Why can't I get it to work without sudo?
Can dbadmin traverse /home/ec2-user? Try doing chmod a+x /home/ec2-user
There could be more reasons for being denied, like a specific acl or a LSM but this is the most likely cause.
UNIX permissions on directories
The UNIX permissions rwx¹ work on directories as follows:
r: You can view the contents of the directory (the names of the files or folders inside)
w: You can create new files, delete or rename existing files.
x: You can traverse the folder.
The traverse permission means that you can access the folder children (assuming you know its name -which you can obtain if you also have read permission-).
In this case dbadmin could read and traverse / as well as /home, but /home/ec2-user probably had a mode like drwx------ 2 ec2-user in order to protect its contents. Thus, even if you had an important file readable by anyone deep inside your home folder, other users can't get into it, since they wouldn't be able to go pass /home/ec2-user (which is exactly what you wanted to do, in this case).
¹ Note that I am skipping over the more exotic ones.
what is the result of ls -la for this dir and also parent dir? Maybe the directory doesn't have read permissions for your user.
sudo chmod ug+r vertica1
Also ec2-user directory should be writable by the user dbadmin.
I would like to ensure that in only one particular directory on linux server will have newly-created directory setup particular group?
I.e.:
I have directory /data with ownership "user1:global_group" and every new subdirectory should have group ownership the same. Once I create directory by using mkdir /data/subdir1 under user1 or user2 the ownership is "user1:grp_user1" or "user2:grp_user2".
How can I manage the subdirectory ownership?
Many thanks for any ideas ...
You need chmod for that.
Apply this: chmod g+s directory on a parent directory. Every newly created file and directory, recursively, will have the group of the parent directory.
So:
chgrp target_group target_directory
chmod g+s target_directory
mkdir -p target_directory/subdirectory/another_one
ls -l target_directory/subdirectory/another_one
And observe, how another_one directory has the desired group.
Use -R or --recursive option. And try chgrp --help first.
I was wondering if anyone could explain a bit on Linux permissions for me. I have two groups
Group A - Normal Users
Group B - File Changing group
I want group B to be pretty much exactly the same as group A other than group B are able to change 'message of the day' how could I set it so they have write access to MOTD and group A only have read access?
With ordinary UNIX u-g-o permissions, you can only assign a single UNIX group to any given file. In your case, since "normal users" presumably means "all users", you could just chmod the MOTD file to 664 (group read-write, all read-only), and chown it to root:file_changers (file owned by root, and assigned to the file_changers group).
With Linux ACLs, you can assign multiple groups to a file. Not all filesystems support ACLs. You can use setfacl to alter the permissions:
setfacl -m g:regular:r motd
setfacl -m g:file_changers:rw motd
Note that, in my opinion, ACLs can often be overkill. They can make permission management a hassle if you aren't prepared for them. Consider carefully if you need them; otherwise, stick to the simpler UNIX permission system.
Solution without ACL:s:
You can move the motd file in a directory that is readable by group A and make the file writable by group B. Then place a symlink in place from the original location to the new location.
Example (assuming motd is in /etc/motd):
# mkdir /etc/motd-dir
# mv /etc/motd /etc/motd-dir/
# chown groupA /etc/motd-dir
# chown groupB /etc/motd-dir/motd
# chmod 750 /etc/motd-dir
# chmod 664 /etc/motd-dir/motd
# ln -s /etc/motd-dir/motd /etc/motd
This solution requires that all members of group B must also belong to group A so they can access the directory.