I want to set a directory to
-rwx r-x r-x
using the octal form of chmod
what should i type in the terminal after chmod?
and how do i calculate the digits in octal form?
It goes like this:
rwx rwx rwx
421 421 421
so what you want is
rwx r-x r-x
421 4-1 4-1
7 5 5
so you type
chmod 755 nameofdirectory
Related
While assigning permissions to a file with the command:
$ chmod +rwx file1.txt
Why is it that read and execute permissions are assigned to everybody, but write permission is only assigned to the user?
yes it depends on the umask of your system u might be having 0022 as your umask
chmord +rwx file.txt ---- 777
the resulting permission 777-022=755
chmod(1)
A combination of the letters ugoa controls which users' access to the file will be changed: the user who owns it (u), other users in the file's group (g), other users not in the file's group (o), or all users (a). If none of these are given, the effect is as if (a) were given, but bits that are set in the umask are not affected.
This is pretty clear. You have to check your umask value:
$ umask
0002
$ touch xyz
$ ls -l xyz
-rw-rw-r-- 1 user user 0 Sep 6 22:56 xyz
$ chmod +rwx xyz
$ ls -l xyz
-rwxrwxr-x 1 user user 0 Sep 6 22:56 xyz
$ chmod a+rwx xyz
$ ls -l xyz
-rwxrwxrwx 1 user user 0 Sep 6 22:56 xyz
Have a look at this page: Default File Permissions: umask
I checked that umask value is 0022 in my Linux machine and I know the way to find permissions is as follows:
Directory base permissions: 777
umask value: 022
Subtract to get permissions of new directory (777-022) : 755 (rwxr-xr-x)
I have a structure like $ src/x/B.java so when I checked permissions for src it was:
drwxr-xr-x 4 gtee staff 136 Feb 17 23:17 src
i.e. 755 (777-022) which is as per above .
But when I checked permission for x it was:
dr-xr-xr-x 4 gtee staff 136 Feb 17 23:17 x
i.e. 555, but how this value is assigned? I don’t understand this.
As x is also a directory, why isn’t it 777-022?
If I mount the sshfs server with no umask, i get -rw-rw-r-- on new created files. If I try and open a php file on the server on my browser, i get this error:
Incorrect file/directory permissions: Above 755.
In order files to be processed by the webserver, their permissions have to be equal or below 755.
So I tried with umask=0022: the new created files have -rwxr-xr-x. These permissions are fine, as the error above does not appear anymore. However, I can't understand why the new files are set as executables...
Could you please explain? Many thanks...
From sshfs manual:
-o umask=M
set file permissions (octal)
Note the manual mentions the option name is umask. So it is not the same values you would use in chmod, where 7 means rwx (binary 111). Instead, umask is a mask, as the name says.
For fuse, this mask is used as an inversion of the desired permission.
Then, from http://wiki.gilug.org/index.php/How_to_mount_SFTP_accesses#General_working_of_umask, we get the following:
[umask i]s a template-mask. Is as a chmod inverse, because is used for shading the permissions to be set when creating files and directories. As higher is the octal value, more restrictive (at binary level a bit 1 shades an attribute and a bit 0 allows it).
0 allows rwX
1 allows rw-
2 allows r-X
3 allows r--
4 allows -wX
5 allows -w-
6 allows --X
7 allows ---
So, if you supply 0022, the permission will go as follows:
AND with 0777 (see umask man page) to consider only "user", "group" and "others" permissions (i.e. discard first part of the mask).
000 000 010 010 -> 0022
AND
000 111 111 111 -> 0777
=
000 000 010 010 -> 0022
Invert the three permissions.
000 010 010 -> 022
becomes
111 101 101 -> 755
If you don't want the files to be executable, but want them to be readable and writable (chmod 666), you should set umask to:
110 110 110 = 666 <- chmod value
001 001 001 = 111 <- umask value
The umask sshfs option only deals with how the remote files appear to you on your local system, this shed some light on the issue for me: serverfault.com/q/228396, a desired umask of 0002 for remotely created files and folders was achieved with:
Lines appended to /etc/pam.d/sshd on the remote system:
# Setting UMASK for all ssh based connections (ssh, sftp, scp)
session optional pam_umask.so umask=0002
This one has been a long-running issue for me, cheers.
In fuse drivers the umask option does not work intuitively.
It doesn't mask existing permissions. Instead it sets the permissions to its inverse.
It only applies when reading. For sshfs new files and folders have their permissions set according to the sshd config on the remote host.
And the combination of the two means there's no way to see what the remote permissions actually are if umask is set.
Some drivers offer separate fmask/dmask options to avoid making everything executable, but sshfs is not one of them. If you want no files to be executable then the noexec will work (but not be reflected in the permissions). If some files should be executable and others not, then it's not possible.
Some filesystems allows to set masks separately for directories and files with dmask and umask, which would allow you to disable executable bit for files. I'm not sure if sshfs offers it, others have asked for it -> https://superuser.com/questions/1020582/fuse-file-system-fmask-and-dmask.
You can set noexec option for whole filesystem if you don't want any user to execute any files.
I have this old Perl script. This script is working from cron on CentOS 6.4. It creates a temporary directory and is trying to unzip files there.
This is a piece of code:
$lg->li("Creating Directory... \n\t$unzip_dir");
mkdir ($unzip_dir, 0777) or my_die("mkdir $unzip_dir failed") unless (-e $unzip_dir && -d $unzip_dir);
However after execution the directory has weird permissions:
drwxrwsr-x 42 buser agroup 12K Dec 30 09:18 .
drwxrwsr-x 4 buser agroup 4.0K Apr 6 2012 ..
drw-rwSr-- 2 auser agroup 4.0K Dec 28 11:51 tm_unpack_dir_1388412502.20184
The umask for user auser is a 0002.
Why the new directory has no execution permission? Any idea, how this can happen?
The weird permissions are caused by the setgid bit on the parent directory in combination with an unusual umask:
Look at the permissions of the parent directory, the first line:
drwxrwsr-x 42 buser agroup 12K Dec 30 09:18 .
drw-rwSr-- 2 auser agroup 4.0K Dec 28 11:51 tm_unpack_dir_1388412502.20184
Notice it has rwxrwsr-x which means that the setgid bit is set. The setgid bit on a directory causes new files in the directory to be created with the same group as the directory. New directories inherit the setgid bit from their parent.
A umask of 0113 will cause the strange permissions you're seeing. That is an unusual umask, the default is 0022. The umask is set in the environment executing the script, or directly in the script itself.
Don't worry about 0777 after mkdir in your script: mkdir $dir, 0777 means "create $dir without interfering with the present umask". 0777 is the default and can be safely omitted.
Try setting the umask directly in your script:
umask 0022;
$lg->li("Creating Directory... \n\t$unzip_dir");
mkdir ($unzip_dir) or my_die("mkdir $unzip_dir failed") unless (-e $unzip_dir && -d $unzip_dir);
should cause:
drwxrwsr-x 42 buser agroup 12K Dec 30 09:18 .
drwxr-sr-x 2 auser agroup 4.0K Dec 28 11:51 tm_unpack_dir_1388412502.20184
New directory permissions are rwxr-sr-x which is more normal. Notice that the setgid bit is still set because of the parent directory.
Oh, you might wonder why the setgid bit is sometimes lowercase 's' and sometimes uppercase 'S'. That depends on the executable bit. Lowercase s means the executable bit is set, uppercase means it's not set:
$ mkdir foo
$ ls -l
drwxr-xr-x 2 johan johan 4096 Dec 30 17:22 foo
$ chmod g+s foo
$ ls -l
drwxr-sr-x 2 johan johan 4096 Dec 30 17:22 foo
$ chmod g-x foo
$ ls -l
drwxr-Sr-x 2 johan johan 4096 Dec 30 17:22 foo
Your code looks correct to me.
Confirming on my system:
perl -e 'mkdir("foo", 0777);'
drwxr-xr-x 2 user user 512 Dec 30 10:48 foo
mkdir is affected by your umask. A funky umask can do funky things.
What does this yield for you?
perl -e 'printf("%04o\n", umask());'
I get this:
0022
Which is why my folder is created 0755 when I ask for 0777.
I've debugged script and found source of the problem.
The problem caused by tar.gz archive sent to us by one of our submitters. These tar files having directory without execution permission set. I have no idea how they achieve such result.
One more problem - the Gnu Tar have no key to prevent restoring files and directories permissions.
So after extracting archive with wrong permissions I have to recursively set right permissions on the all files and directories in the archive.
Thank you everybody.
It means that the setuid and setgid bits have been set.
The setuid (set user id) is a permission bit, that allows the users to exec a program with the permissions of its owner.
The setgid (set group id) is a bit that allows the user to exec a program with the permissions of the group owner.
http://linuxg.net/how-to-set-the-setuid-and-setgid-bit-for-files-in-linux-and-unix/
I am new to Linux. I am making some trials with the umask command. I set the umask to 001 but when I create a file and the display a long list, the new file does not show allowed-execution permission. I wonder why?
Umask is a bit special. What setting a bit means is that you are actually disabling the permission. It implementation is:
(not umask) & filemode
The filemode is what the user would like to create.
So you disabled the execution bit:
001 -> complement -> 110 -> rw-
The mask you want to try is 110 (bits) or 006 (octal) :)
The umask tells the system which bits to remove from the mode bitmask given at the creat() call. The umask is usually represented as an octal number, each digit consisting of 3 bits (r=4, w=2, x=1). The three octal digits stand for "user", "group", "other".
It is up to the program if it calls creat with the mode 666 for rw- or 777 for rwx. In this case, obviously 666 is used. (A file is normally created with 666 unless it is supposed to be executable. In this case, 777 is used. This counts e. g. for compilers.)
A very common umask is 022 (octal). It turns 666 (rw-rw-rw-) into 644 (rw-r--r--) and 777 (rwxrwxrwx) into 755 (rwxr-xr-x) These are, respectively, the file modes which are eventually applied to the file.
Your umask 001 would only switch off the x bit of the "others" group. So 777 would become 776 (rwxrwxrw-), and 666 stays 666 (rw-rw-rw-).
It could be that the system admin has set up a umask exception to not allow execute permissions to occur by default. See this article for more information:
http://boulderapps.co/on-create-a-new-file-why-are-the-execute-permissions-not-set-to-my-umask