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.
Related
We are getting the error "permission denied" when trying to write to a file that is owned by a service user and a shared group. In particular that is www-data:www-data and the user trying to write to it is in the group www-data.
There is no acl on none of the parent folders and the permissions to the file and folders are correct.
Here some details:
$ sudo -u deploy id -Gn
www-data
$ ls -lah /tmp
drwxrwxrwt 17 root root 4.0K Jul 11 11:22 .
drwxr-xr-x 23 root root 4.0K Jul 8 10:08 ..
...
-rw-rw-r-- 1 www-data www-data 0 Jul 11 10:50 test
...
$ echo 'hello world' | sudo -u deploy tee -a /tmp/test
tee: /tmp/test: Permission denied
hello world
we tried that on different folders and made sure there is no acl on any of the folders or parents or files...
Unfortunately that is not described in the link stark posted in the comment. And also not in any other page I found until I found an answer here on stackoverflow that clarified it.
2018 two new filesystem configurations got added to sysctl that should prevent regular files and fifos from beeing opened with the O_CREAT flag (as append mode is doing) in directories with the sticky bit set unless the user is the owner of the file. This commit added the settings: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=30aba6656f61ed44cba445a3c0d38b296fa9e8f5
To change that behaviour you have to set fs.protected_regular to 0:
sudo sysctl fs.protected_regular=0
Or to persist the change add fs.protected_regular=0 to your sysctl.conf.
side node: since O_CREAT is not deleting or renaming the file I'm wondered why it is connected to the sticky bit. It really is possible to create a file in directories with the stick bit set.
I am trying to use rsync to backup some data from one computer (PopOS! 21.04) to another (Rocky 8.4). But no matter which flags I use with rsync, file permissions and ownership never seem to be saved.
What I do, is run this command locally on PopOS:
sudo rsync -avz /home/user1/test/ root#192.168.10.11:/root/ttt/
And the result I get something link this:
[root#rocky_clone0 ~]# ls -ld ttt/
drwxrwxr-x. 2 user23 user23 32 Dec 17 2021 ttt/
[root#rocky_clone0 ~]# ls -l ttt/
total 8
-rw-rw-r--. 1 user23 user23 57 Dec 17 2021 test1
-rw-rw-r--. 1 user23 user23 29 Dec 17 2021 test2
So all the file ownership change to user23, which is the only regular user on Rocky. I don't understand how this happens, with rsync I am connecting to root on the remote host, but as the result files are copied as user23. Why isn't -a flag work properly in this case?
I have also tried these flags:
sudo rsync -avz --rsync-path="sudo -u user23 rsync -a" /home/user1/test root#192.168.10.11:/home/user23/rrr
This command couldn't copy to the root directory, so I had to change the remote destination to user23's home folder. But the result is the same.
If someone could explain to me what am I doing wrong, and how to backup files with rsync so that permissions and ownership stay the same as on the local computer I would very much appreciate it.
Have a look at how the (target)filesystem is mounted on the Rocky(target) system.
Some mounted filesystems (such as many FUSE mounts) do not support the classical unix permissions, and simply use the name of the user who mounted the filesystem as owner/group.
Any attempt to chown/chmod/etc (either by you or by rsync) will just silently be ignored, but appear to "succeed" (no errors reported).
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 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 currently messing around on my linux system and now I have the following situation.
The directory /srv/http has the following permissions set:
drwxrwxr-x 2 root httpdev 80 Jun 13 11:48 ./
drwxr-xr-x 6 root root 152 Mar 26 13:56 ../
-rwxrwxr-x 1 root httpdev 8 Jun 13 11:48 index.html*
I have created the group httpdev before with the command:
groupadd httpdev
and added my user sighter with:
gpasswd -a sighter httpdev
Then I have set the permissions as above using the chown and chmod commands.
But now I am not allowed to modify the index.html file or create a new file, as user sighter ,with touch like that:
<sighter [bassment] ~http> touch hallo.php
touch: cannot touch `hallo.php': Permission denied
What do I understand wrong. I was expecting that I can do what I want there then the group has all the rights.
The following Output is for your information.
<sighter [bassment] ~http> cat /etc/group | grep sighter
...
httpdev:x:1000:sighter
...
The used linux-distro is archlinux.
Adding a user to a group does not affect currently running sessions. So you have to logout and login again or use su - sighter to login.
After this you should be able to do what you want to do.
You're not in the right group. You need to log out and back in again. Also, superuser.