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.
Related
We have complaints "from the field" (i.e. from sysadmins installing software) that cygwin "messes up" windows permissions on NTFS (Windows 7/10/2008/2012, etc).
Problem Usecase
The general usecase is this:
Sysadmin launches some 'software installer' from the cygwin bash cmd line
Installer runs fine
Sysadmin tries to start windows services
Result:
Service fails to start
Workaround Steps
These steps seem to get past the problem:
Sysadmin resets ntfs permissions with windows ICACLS command : (in this example "acme" is the newly created directory. This command sets acme and its children to re-inherit permissions from folder "d:\instances"
d:\instances> icacls acme /RESET /T /C /Q
Sysadmin starts service
Result:
Windows service starts
Question
What makes cygwin handle permissions for newly-written files differently than powershell? Is it a matter of a wrong version of umask?
Can the sysadmin take steps in advance to ensure cygwin sets up permissions properly?
thanks in advance
I found the answer here; it refers to this mailing-list letter.
You need to edit Cygwin's /etc/fstab and add "noacl" to the list of mount-options.
To add to the answer of ulathek here is the copy-paste of the two URLs:
First:
How to fix incorrect Cygwin permission in Windows 7
Cygwin started to behave quite strangely after recent updates. I was not able to edit files in vim, because it was complaining that files are read only. Even cp -r didn’t work correctly. Permission of new directory was broken and I was not able to remove it. Pretty weird behavior.
E.g. ls -l
total 2
----------+ 1 georgik None 34 Jul 14 18:09 index.jade
----------+ 1 georgik None 109 Jul 14 17:40 layout.jade
Hm. It is clear that something is wrong with permission. Even owner has no permission on those files.
Output of mount command:
C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
I found a solution at cygwin forum. It’s quite easy to fix it.
Open /etc/fstab and enter following line:
none /cygdrive cygdrive binary,noacl,posix=0,user 0 0
Save it. Close all cygwin terminals and start new terminal.
Output of mount:
C: on /cygdrive/c type ntfs (binary,noacl,posix=0,user,noumount,auto)
Output of ls -l
total 2
-rw-r--r-- 1 georgik None 34 Jul 14 18:09 index.jade
-rw-r--r-- 1 georgik None 109 Jul 14 17:40 layout.jade
Second:
7/14/2010 10:57 AM
> Drive Y is a mapping to a network location. Interestingly, ls -l
>> /cygdrive returns:
>> d---------+ 1 ???????? ???????? 24576 2010-07-09 11:18 c
>> drwx------+ 1 Administrators Domain Users 0 2010-07-14 06:58 y
>>
>> The c folder looks weird, the y folder looks correct.
>>
> Try ls -ln /cygdrive. The user and group ownerships on the root of the
> C: drive are most likely not found in your passwd and group files. The
> -n option for ls will print the user and group IDs rather than try to
> look up their names. Unfortunately, I can't think of any way offhand to
> generate the passwd and group entries given only user and group IDs.
> Maybe someone else can comment on that.
>
I think your answer is correct:
$ ls -ln /cygdrive
total 24
d---------+ 1 4294967295 4294967295 24576 2010-07-09 11:18 c
drwx------+ 1 544 10513 0 2010-07-14 11:45 y
I edited my /etc/fstab file (it contained only commented lines) and
added this line at the end of the file:
none /cygdrive cygdrive binary,noacl,posix=0,user 0 0
I closed all my Cygwin processes, opened a new terminal and did an ls-l
on visitor.cpp again:
-rw-r--r-- 1 cory Domain Users 3236 2010-07-11 22:37 visitor.cpp
Success!!! The permissions are now reported as 644 rather than 000 and I
can edit the file with Cygwin vim and not have bogus read-only issues.
Thank you Jeremy.
cory
I am using docker on ubuntu 16.04 with user id mapping (user namepsaces) enabled. I have following settings:
/etc/passwd
myusername:x:1000:1000:,,,:/home/myusername:/bin/bash
/etc/subuid
myusername:100000:65536
/etc/subguid
myusername:100000:65536
When I start a container the files are being correctly mapped from 0 (root) to my subuid 100000.
host
-rw-r--r-- 1 100000 100000 0 Mär 30 13:05 testfile
container
rw-r--r-- 1 root root 0 Mar 30 13:05 testfile
I can read the file on the host machine, but I cannot edit it. My assumption was that 100000 is "my" subuid, so I can edit those files. How can I achieve that those files are accessible by myusername without sudo?
I'm not sure how to fix this with user namespace mapping but you can work around it with ACL's.
If you don't mind leaking some UID information into the container, you can add an ACL to the directory for your host user. ACL's sit on top of the standard POSIX permissions.
To set a default ACL on the parent directory, that new entries inherit:
setfacl -d -m u:1000:rwx volume_dir/
To set the ACL on all existing files and directories in a directory:
setfacl -R -m u:1000:rwX volume_dir/
The X auto detects directories and sets them to executable but skips making files executable. Unfortunately this type of differentiation is not available on the default ACL.
My linux umask is 002.
$ umask
0002
Therefore new files have 664 permissions.
$ touch new-file
$ ls -l
-rw-rw-r-- 1 david www-data 0 feb 11 11:37 new-file
However if I create a new file from netbeans (right click / New / Empty file) it have 644 permissions.
$ ls -l
-rw-r--r-- 1 david www-data 0 feb 11 11:40 netbeans-file
Can I configure which permissions have new files created from netbeans?
As #tripleee says Netbeans was not a child of the shell where umask were set.
umask command were at .bashrc which is executed only when a shell window is opened but not on session login.
After moving the umask command to .profile all GUI programs including netbeans take the umask properly.
umask is a mask with it the intended permissions, when creating a file, are mixed. That means that if Netbeans wanted a file with rw-r--r-- and the mask is 002 (means that you want to remove writing for others), real protections will be rw-r--r--. The operation behind this is:
real_rights = wanted_rights & ~umask
An application have preferences about protection over a file it creates, and user have preferences on what he do not want on permissions.
The commands
cd c:/p4
ls -ld . c:/p4 /cygdrive/c/p4
shows
d---------+ 1 jgunter Domain Users 0 Apr 27 18:41 .
d---------+ 1 jgunter Domain Users ? 0 Apr 27 18:41 /cygdrive/c/p4
drwxr-xr-x 1 jgunter Domain Users ? 0 Apr 27 18:41 c:/p4
ls shows the perms I want to see only for files specified with a C:/ path.
I know about getfacl, but I'm hoping there's some ls option that will show me what I want without requiring I spell out absolute paths.
I can do something like:
ls -ld `cygpath -da $#`
but when I'm in a deeply nested folder, the output is cluttered by full pathnames.
DOS path makes cygwin treat the file system as not having ACLs. It means that ls shows the correct ACLs, but the same directory is mounted with different options. Therefore ls doesn't have such an option, you need a workaround.
https://cygwin.com/cygwin-ug-net/ov-new1.7.html states at 1.7.2:
Handle native DOS paths always as if mounted with "posix=0,noacl"
Beside this, I think, that d---------+ is strange. I've tried it on my PC, with 1.7.31 cygwin version, and it shows drwx------+, which is a bit better. I had experienced other bugs and strange behaviour in cygwin ACL handling. I guess there is confusion and some hacks about this. chmod 777 was a good workaround in my case.
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