At the moment, I paste files to a directory in Linux and it sets the following permissions:
rwxr--r--
What I'm trying to do is to set the permission to
rwxrw-r-- (group write)
automatically when I paste a new file into that folder or after a given period, preferably the one more efficient.
There must be an elegant solution to that already, if so can you point me the direction, please?
These "default rights" are called "umask" in the UNIX world (see wiki).
I think your problem can be solved by appending a umask command to the /etc/profile script:
umask 013
Depending on your distributive, there can also be other ways to set umask.
Related
While reading about open syscall and in more details the parameters we send, I read:
The umask acts as a set of
permissions that applications cannot set on files. It's a file mode
creation mask for processes and cannot be set for directories itself.
Most applications would not create files with execute permissions set,
so they would have a default of 666, which is then modified by the
umask. As you have set the umask to remove the read/write bits for
the owner and the read bits for others, a default such as 777 in
applications would result in the file permissions being 133. This
would mean that you (and others) could execute the file, and others
would be able to write to it. If you want to make files not be
read/write/execute by anyone but the owner, you should use a umask
like 077 to turn off those permissions for the group & others. In
contrast, a umask of 000 will make newly created directories readable,
writable and descendible for everyone (the permissions will be 777).
Such a umask is highly insecure and you should never set the umask
to 000. The default umask on Ubuntu is 022 which means that newly
created files are readable by everyone, but only writable by the
owner.
Can someone kindly explain what is this mask in general? I never heard of it before?
The umask value determinants the permissions given to a file when is created, the default permissions given to a file, after is created you can change it with chmod.
If you want to check the value setting, you have to execute the command “umask”, this could tell you the value as default that the user has to create files.
If you want to change the umask value you can run the following command to set it.
umask 022
Keep in mind that the numbers that are you described in the command above are the permissions that won't give to the file, so, in this case, will be generated with 755.
There's an external server that deposits some files inside a folder of my computer.
I need to automatically change the user ownership of every file created inside that folder.
I've seen a lot of answers saying that I could just change the GROUP ownership through setfacl (from my research it is not possible to change the USER ownership through setfacl).
In this case, I can't, because there's a script owned by the user A (not root) that is going to chmod this deposited file owned by the user B, and you can only chmod a file that you own.
Instead of this (inside the script):
chmod 777 /folder/file.txt
I tried this:
sudo chmod 777 /folder/file.txt
But a password is asked and BAM!
Do you have any ideas on how to deal with this?
Am I missing something?
I am not sure what you want to achieve, so here's a couple of suggestions:
if the goal is simply for the file to have specific permission settings, and ownership change is secondary, you could set the permissions correctly on the source computer and then use a transfer method that preserves permissions (scp -p or some such)
note that a script owned by A can still be run by B if A has set the permissions correctly (group and other executable bit). When B runs A's script, it runs with B's permissions, so changing permission bits of B's file will work
if ownership change is imperative, you could transfer the file to B, make sure A has permission to read (see above), and then have A make a copy of the file to A's own directory using the cp command. The copy will be owned by A and thus A can change permissions of the copy. After that, run some regular process to clean up B's directory in order to save space if that's an issue
alternatively, you could have B on the source computer log into A's account on the receiving computer, and then the file ends up in A's ownership. If you do not want to give B the password of A, you could do this using an ssh certificate. But of course this has other security risks, so the cp method above is safer
finally, on unix it is generally not a good idea to make files writable for "other", and often not even for "group", so permission settings of 775 or 755 are much safer and preferred. Otherwise anyone on the same computer could modify the file or make it an empty file. Even on a private computer this is good practice, because sooner or later one of these files will get copied to a multi-user system and no-one remembers to check the permissions
Hopefully some of these hints are useful.
One way may be to use the group sticky bit on the parent directory. This ensures that when created the files are given the same group ownership as the directory that they are in.
In most cases this is enough as you can ensure that the group is one that the file creator and the users all are members of, so they all have access to the files.
You can sticky the user ID of the directory, but this is almost always the wrong thing to do in an organisation, as it only takes that person to be away and the directory overflows.
chown owner:group directory -R
Example:
chown root:root sysadmin -R
try this.
In a script, should I create a file first and then, use CHMOD to assign permissions (Example- first using TOUCH command to create a file and then, using CHMOD to edit permissions on that file) "OR" should I mask permissions using UMASK as I create a file ? Also, please explain what are the pros and cons of choosing one over another ?
Note: This file doesn't need to be executed.
As with most things, it depends on far more information than you've given :-)
However, it's usually a good idea to do things in a closed manner then open them up, rather than the other way around. This is basic "Security 101".
For example, let's say you're creating a file for the user and the user has foolishly selected a umask of zero (effectively all files created will have full permissions for everyone).
In that case, the file is fully open for anyone to change between the creation and chmod stage and, while you can minimise this time, you cannot really remove it totally.
For the truly paranoid among us, it would be better to actually create the file in as closed a manner as possible (probably just rw for owner), do whatever you have to do to create the content of that file, then use chmod to open it up to whatever state it needs to be, something like:
( umask 177 ; create_file myfile.txt ; chmod 644 myfile.txt )
Briefly saying - it doesn't matter. And in most cases approach depends on your needing.
If you need the same file permissions over whole your script logic, I would prefer to setup it in the beginning of the script and just create file rather than create and run chmod command. However you can set file permissions at once at the end of script running chmod 0XXX -R /path/to/folder
You should always have UMASK for specific user as you don't want to be dealing with setting permissions every-time you or an application create a file. You can further protect/release any specific files if you want using CHMOD (these cases will be very rare). Unless the file you are creating needs to be protected/accessed specifically, you should have a UMASK working for it's permissions.
Create a separate user and specified directory for the application that is running the script.
set it's appropriate UMASK.
Specify extra permissions if you need it
When I load GVim from the Cygwin command line or when I'm not connected to the office network (mapped to U:/) it loads instantaneously. It takes a good minute or so to open when I'm on the network. What is going on here?
You probably need to set your $HOME directory to something other than U:/. Create a $HOME environment variable for Windows that points to My Documents or whatever and it won't try and use U:/. You may need to log-off/log-in to pick up the changes.
You should check what your $HOME directory is mapped to in each case. I bet that it is different depending on if you are connected to the network or not.
Do you have any custom .vimrc or other config files read at startup? If nothing else, vim will query your $HOME directory to look for such files. If your network is slow, it could cause your problem.
See ":help startup" inside vim for more details on the startup process.
It might also be a good idea to set the directory and backupdir options so they prefer a local directory. Something along the lines of
set backupdir^=C:/Temp
set directory^=C:/Temp//
The ^= syntax puts the directory at the start of the list of directories for each option. The trailing // for directory tells Vim to encode the full path to the file being edited in the swapfile's name. This allows for swapfiles to be created in one directory when editing multiple files with the same name, but different paths.
Is it possible to setup directory permissions such that a group is able to read and write files and subdirectories but not delete anything?
It might be enough to set the sticky bit on the directories. Users will be able to delete any files they own, but not those of other users. This may be enough for your use case. On most systems, /tmp is setup this way (/tmp is set 1777)
chmod 1775 /controlled
However, If you want more control, you'll have to enable ACL on the filesystem in question.
In /etc/fstab, append acl to the flags:
/dev/root / ext3 defaults,acl 1 1
You can then use setfacl/getfacl to control and view acl level permissions.
Example: (Create files, once written, they are read only, but CAN be deleted by owner, but not others.)
setfacl --set u::rwxs,g::rwx /controlled
setfacl -d --set u::r-x,g::r-x,o::- /controlled
You can set a default acl list on a directory that will be used by all files created there.
As others have noted, be careful to specify exactly what you want. You say "write" - but can users overwrite their own files? Can they change existing content, or just append? Once written, it's read only? Perhaps you can specify more detail in the comments.
Lastly, selinux and grsecurity provide even more control, but that's a whole other can of worms. It can be quite involved to setup.
Well, it would be r-x for this directory.
And files in it would have rw-.
This is because a file can be written if its permissions allow Write, but it can only be deleted if its directory's permissions allow Write.
Possible or not, make sure that overwriting with a 0-byte file isn't equivalent to deleting the file in your particular context.