Is there someway to set the default file permission in Linux? That is, the file permission for a newly created file (regardless of the context for which it was created
). I know about putting umask in the shell startup but that only works for shell sessions. When I transfer files to a Linux box using pscp, the file is always created with permissions of 664 (rw-rw-r--). The has occurred across every flavor of Linux that I've used. This is especially annoying when I pscp a file to shared Linux machine (like my ISP). Until I can shell in and chmod the permission, the file is basically sitting there with read access for everyone, which is not exactly secure.
Put the umask in the non-interactive shell startup (.bash_profile, .zshenv, .tcshrc depending on your shell). Then it'll run for non-login sessions.
If you want to affect the whole system, you can also put it in /etc/profile
Related
I installed Apache in my server and it all looks fine. The problem is that everytime I create a folder/file it does not have 777 permission, I need to use chmod to every folder/file I create to assign 777 permission. How can I create a permission rule that will be the default to new files/folders ?
While I agree 777 is not a good idea, the answer is umask:
umask 000
I recommend the following at least so not everyone in the world (well, with access to that machine) can write there:
umask 002
Oh, and these don't inherit by the directory. Use ACLs instead to get inheritence. ACL tools vary from OS to OS. Try "setfacl" or "chacl".
The short answer is that you can't and you shouldn't even if you could. Having any file on the file system with 0777 as the mode is a very bad idea.
The slightly longer answer is that the Apache process controls the mode that it creates new files with as the third argument to open(2) or by using fopen(3). In the latter case, the mode is 0666 by default. Whatever mode is passed in is further modified by the process's umask value. If a process has a sane umask (such as 022), then the result of opening a file with fopen will be a file with its mode set to 0666 & ~022 = 0644. I guess if the process were to use open to create a file with 0777 and the process umask was set to 0, then the file that it creates would have 0777 as the resultant mode.
Is it possible on Linux or MacOSX to prevent a Unix domain socket file (e.g. in /tmp) that is currently bound from being deleted? I want a mode 0777 socket that users can connect to but that users cannot delete while the daemon is running.
Right now a normal user can 'rm' the socket, preventing anyone else from accessing it until the daemon is restarted. Seems like it should be 'busy' if it's bound.
You could make a new subdirectory and set read only permissions on the directory after you make the socket:
mkdir /tmp/blah
cd /tmp/blah
# do stuff to create /tmp/blah/socket
chmod 555 /tmp/blah
rm /tmp/blah/socket
rm: cannot remove /tmp/blah/socket: Permission denied
(or the equivalent to that from C / your language of choice)
It depends entirely on the directory that contains the socket. /tmp is somewhat special in that it has the "sticky bit" set on the directory (if you execute ls -ld /tmp you will see the permissions field is usually: drwxrwxrwt or, more usefully, mode 1777. That sticky bit (the t at the end) is important when set on a directory. Quoting man chmod:
The restricted deletion flag or sticky bit is a single bit, whose interpretation depends on the file type. For directories, it prevents
unprivileged users from removing or renaming a file in the directory unless they own the file or the directory; this is called the re‐
stricted deletion flag for the directory, and is commonly found on world-writable directories like /tmp. For regular files on some older
systems, the bit saves the program's text image on the swap device so it will load more quickly when run; this is called the sticky bit.
This is exactly what you want - file-system level protection against a user removing the file. It is also 100% portable to all modern UNIX-like environments.
So, if you are creating your endpoint in /tmp you already have the protections you want. If you want to create the endpoint elsewhere, for example /opt/sockets, simply chmod 1777 /opt/sockets. The last part of the "trick" to getting the protections you want is to ensure that the root user is the actual owner of the endpoint. If the endpoint is owned by user fred then fred will always be able to delete the endpoint, which may well be a desirable thing. But if not, simply chown root:root /path/to/endpoint.
Here is my problem,
In Windows I am making a zip file in which there is a text .sh file which is supposed to be executed in Linux.
The user on the other end opens the zip file in Linux and tries to execute the .sh file but the execute permission is gone. So the user has to do it manually ( like explained here:add execute permission.
How can I in Windows make the .sh executable and add it to a zip file so that when the zip file opens in linux the .sh file still retains its execute permission ( so that user doesn't have to do it manually)
As far as I know the permission system in Linux is set up in such a way to prevent exactly what you are trying to accomplish.
I think the best you can do is to give your Linux user a custom unzip one-liner to run on the prompt:
unzip zip_name.zip && chmod +x script_name.sh
If there are multiple scripts that you need to give execute permission to, write a grant_perms.sh as follows:
#!/bin/bash
# file: grant_perms.sh
chmod +x script_1.sh
chmod +x script_2.sh
...
chmod +x script_n.sh
(You can put the scripts all on one line for chmod, but I found separate lines easier to work with in vim and with shell script commands.)
And now your unzip one-liner becomes:
unzip zip_name.zip && source grant_perms.sh
Note that since you are using source to run grant_perms.sh, it doesn't need execute permission
The ZIP file format does allow to store the permission bits, but Windows programs normally ignore it.
The zip utility on Cygwin however does preserve the x bit, just like it does on Linux.
If you do not want to use Cygwin, you can take a source code and tweak it so that all *.sh files get the executable bit set.
Or write a script like explained here
This is possible using the Info-Zip open-source Zip utilities. If unzip is run with the -X parameter, it will attempt to preserve the original permissions. If the source filesystem was NTFS and the destination is a Unix one, it will attempt to translate from one to the other. I do not have a Windows system available right now to test the translation, so you will have to experiment with which group needs to be awarded execute permissions. It'll be something like "Users" or "Any user"
Use my windows command line utility zip_exec.zip to set the executable flag for linux/unix and mac (tested on files created with Windows Explorer and 7zip). The cpp source is also available. I searched the internet a lot before making my own utility. It can be modified to set any file attribute.
This is not possible. Linux permissions and windows permissions do not translate. They are machine specific. It would be a security hole to allow permissions to be set on files before they even arrive on the target system.
I have a folder /cygwin/d/myfolder/
And everytime I save files there, from cygwin if i do an ls -la I see that the files are given permission 000. That actually causes me quite a bit of problem as I rsync this folder to my server and none of the files are accessible. How can I get the files to automatically get a reasonable permission?
Have a read through the answers at this link:
http://cygwin.1069669.n5.nabble.com/vim-and-file-permissions-on-Windows-7-td61390.html
The solution there worked for me also:
Edit /etc/fstab and add this line at the end of the file:
none /cygdrive cygdrive binary,noacl,posix=0,user 0 0
Then close all Cygwin processes, open a new terminal and ls -l on your files again.
Explanation:
By default, Cygwin uses the filesystem's access control lists (ACLs) to implement real POSIX permissions. Some Windows-native program or process may create or modify the ACLs such that Cygwin computes the POSIX permissions as 000. With the noacl mount option, Cygwin ignores filesystem ACLs and only fakes a subset of permission bits based on the DOS readonly attribute.
Check to make sure that your umask is set correctly with the umask command. If your umask is say 0777 that subtracts from the permissions of new files and will end up with 000 permissions. There's probably several other possibilities to consider beyond that.
If your id is not set up correctly in /etc/passwd and /etc/group that can also cause ls to show unexpected results. Check the permissions of the folder. Also check the Windows permissions with the getfacl command. Maybe also check the mount command.
In above answer, solution was proposed:
Edit /etc/fstab and add this line at the end of the file:
none /cygdrive cygdrive binary,noacl,posix=0,user 0 0
And in that answer there was this comment:
When I try this, all my files are -rw-r--r-- no matter what chmod() I do. I can't mark the files as executable; it just reverts to 0644. (umask==0022)
I had this same problem, but it manifested in inability to execute DOS batch files (*.bat) when running Cygwin ksh or mksh. I stumbled across this website: http://pipeline.lbl.gov/code/3rd_party/licenses.win/cygwin-doc-1.4/html/faq/ which contains this helpful advice:
Note that you can use mount -x to force Cygwin to treat all files under the mount point as executable. This can be used for individual files as well as directories. Then Cygwin will not bother to read files to determine whether they are executable.
So then cross-referencing with this page - https://cygwin.com/cygwin-ug-net/using.html#mount-table - with its advice:
cygexec - Treat all files below mount point as cygwin executables.
I added cygexec to fourth field of my fstab. This did it. My .bat is now executable inside ksh/mksh, which is necessary since I'm running a Jenkins job that calls a Korn shell stack 3 files deep, that I have no modifiable control over. I just needed the .bat to run!
Update: the solution above wasn't quite what I needed, on further testing. It resulted in some executables such as javac and cl to behave oddly (the utilities would print their usage and exit). I think what I needed instead of 'cygexec' was just 'exec'. As the same page notes:
exec - Treat all files below mount point as executable.
On my Win7 PC files were usually
----------+ 1 David None 69120 Jun 17 13:17 mydoc.txt
I tried all of above no luck
Turned out I still had some old historical mount entries in my .zshrc
I deleted these and Bob's your Uncle problem gone away!
I am currently learning LINUX commands and I am wondering how to run commands within the .plan file.
For example i want to a message as would be output from the ~stepp/cosway programs.
I typed ~stepp/cosway "HELLO" but it didn't work. What is the command for that?
Also how do I set all files in the current directory and all its subdirectories recursively to have a group of admin?
The .plan file is a plain text file that is served by the fingerd daemon. For security reasons, it's not possible to execute commands from that file, unless you modify and recompile fingerd on your machine to do so.
Concerning the second part of your question, use chgrp:
$ chgrp -R admin *