I have a technical user which writes a file to a directory. The file is automatically granted permissions (rw-r--r--).
What determines that/why is it exactly 644 instead of any other rights combination?
And what/how do I have to configure so that the automatic permissions when writing the file are rw-rw-rw / 666?
I would like to refrain from a chmod after copying, as this causes continuous additional work - better that every file copied to this directory by that user gets these permissions.
..and bonus question: does this also cover moving a file there?
Thanks!
This is called the umask and it could be set to 600, 644 or 666.
floridopower - you have to modify the umask for that specific user , in order to do this , you have to see the default environment of the system user, run this:
cat /etc/passwd | grep -i thenameoftheuser
And if you see anywhere /bin/bash in the returned string just run this command:
echo "umask 111" >> /home/thenameoftheuser/.bashrc
So if the user is a system user and the home directory of that user is located in the directory /home/ you can safely run the above commands and then run a test ( create a new file with that user and look at the permissions )
Related
I am supposed to give write/edit permission to my directory in /var/lib/mysql/dbname via Linux.
I am unaware of backend UI and i know i just enetered the text "sudu so" # centos machine which displays :
[root#ip-10-0-0-61 centos]#
Can anyone tell how to proceed further as I have always been using WinScp which restricts me to write database files due to present set permissions.
Any user interface file manager that could do this would be really helpful too.
Thanks in advance
You can change files/folders permission with the chmod command. There's a man page here. The full command line to type depends on which permission you exactly need. A basic usage of the command is
chmod [ugoa][+-=][rwx] file
Where
[ugoa] allow you to choose whose permission you want to modify: the owner of the file (u), users member of the group of the file (g), any other users (o) and all users (a)
[+-=] allow you to tell the command if you want to add (+) the selected permissions, remove them (-) or set them as the only permissions of the file(=).
[rwx] allow you to choose the permission : read (r), write (w) or execute (x). There exist other type of permissions explained in the man.
To change the permission of a folder recursively, you can add the option -R to the command.
Very simple just execute the command
chmod 777 -R ./
This will do the trick for you.
There are two things to look at, setting permissions, and ownership.
To do this for an entire directory (be careful with this)
chmod -R {permissions} {directory}
If you're unsure what permissions to use check this guide
To set ownership, use
chown {user:group} {directory} -R
Again be careful with these settings. It's not often you'll want an entire directory full of files to all have the same permissions, and you could be opening yourself up to risks if you do so. Always be explicit and give each file the minimum permissions needed to get the job done.
This has stumped me for a bit now after working on it for a while. I need to change the permission settings of all files and directories so that group and others have no read, write, or execute access except for one specific directory. So far I have tried variations of `
chmod go-rwx | chmod go+rwx 'filename'
Any tips?`
I don't believe there's a solution shorter than a 2 steps pipeline.
Otherwise, you might want to check umask.
umask changes the default permissions on a file on creation (sadly only on file created by the same shell, but you can add this to the .bash_rc/.bash_profile, so that every shell you'll open will do this by default)
umask 077
will set the mask so that every new file will have permissions like 700.
So you might want to just use this so that in the future you won't need to re-launch that pipeline.
EDIT
if the problem was the pipeline itself, then I'd do
cd && chmod -R 700 && cd 'path/to/that/directory' && chmod -R 777
with the double '&' instead of the pipe just because there's not output to pipe, so an && might do the trick
Good morning everyone! I have a bash script starting automatically when the system boots via the .profile file in the users home directory:
sudo menu.sh
The script starts just as expected however, when calling things like ssh UN#ADDRESS inside the script, the known_hosts file gets placed in the /root/.ssh directory instead of the user account calling the script! I have tried modifying .profile to call 'sudo -E menu.sh' and 'sudo -H menu.sh', but both fail to have the known_hosts file created in the users home directory that's calling the script. My /etc/sudoers is as follows:
# Declarations
Defaults env_keep += "HOME USER"
# User privilege specification
root ALL=(ALL) ALL
user ALL=NOPASSWD: ALL
Any help would be appreciated!
Thanks
Dave
UPDATE: so what I did as a work around is go through the script and add 'sudo -u $USER' before specific calls (since sudo is supposed to keep the $USER env var). This to me seems like a very bad way of resolving this problem. It sudo is supposed to keep the USER and HOME directory variables upon launching menu.sh, why would I need to explicitly call sudo once again as a specific user in order to retain that information (even though sudo is being told to keep it via the /etc/sudoers file). No clue, but wanted to update this post for anyone that comes across it until a better solution can be found.
Regarding OpenSSH, the default location for known_hosts is ~/.ssh/known_hosts. Ssh doesn't honor $HOME when expanding a "~" in a filename. It looks up the user's actual home directory and uses that. When you run ssh as root, it's going to interpret that pathname relative to root's home directory no matter what you've set HOME to.
You could try setting the ssh parameter UserKnownHostsFile to the name of the file you'd like to use:
ssh -o UserKnownHostsFile=$HOME/.ssh/known_hosts user#host...
However, you should test this. Ssh might complain about using a file that belongs to another user, and if it has to update the file then the file might end up being owned by root.
Really, you're best off running ssh as the user whose .ssh folder you want ssh to use. Running processes through sudo creates a risk that the user can find a way to do things you didn't intend for them to do. You should limit that risk by using the elevated privileges as little as possible.
This is the second time i've had this occur to me.
I am working on a rails app, and I create a file via touch show.html.haml, and I can do an ls and see the file.
but I am using both WinSCP and SFTP for sublime, and neither can see this file!
WinSCP returns...
and Sublime returns,
Downloading folder "/app/qa/www/htdocs/qa-dashboard/app/views/scripts/" ... 1 file to download
yet it never downloads the file. What is happening here? I've also verified that it wasn't the touch command. i've tried vi'ing the file, and saving it. Same thing.
I've also verified that the hosts are matching.
Additional notes:
I am using elevated_user to create the file, and user, ddavison to edit the file. ddavison is not in the group.
File modes are,
drwxrw-rw- ... .
drwxr-xrwx ... ..
-rw-rw-rw- ... show.html.haml
The permissions on your scripts directory appear to be incorrect:
drwxrw-rw- ... .
^--^-- missing eXecute bit
The execute bit on directories allows the directory's contents to be listed. Since the "group" and "other" perms on the scripts directory do not allow listing, you'll get that error. Most like you're logged in to the shell as the owner of the directory, so you can get listings all you want, but you're logging in as a user OTHER than the owner via winscp, so they're unable to list the directory contents.
I expect the problem is with the permissions on the containing directory -
drwxrw-rw- ... .
Both of those programs probably try to chdir into that directory before retrieving the file. In order to do so, the directory must have x (execute) permissions for the user they are logging in as. Based on what you said, it seems that set 'other' needs +x -
chmod o+x /app/qa/www/htdocs/qa-dashboard/app/views/scripts/
Depending on the users/groups in question, you may want to consider removing write permission -
chmod o-w /app/qa/www/htdocs/qa-dashboard/app/views/scripts/
For directories, the x permission bit isn't execute, rather it's "list the contents of this directory". Since the directory's permissions are only 'rwxrw-rw-', only the owner may list the contents of the directory. Provide "other" that permission using chmod o+x /app/qa/www/htdocs/qa-dashboard/app/views/scripts.
I was trying to write a script which will be able to perform some build-in command ,such as : cp, rm, ls or whatever.
The menu might be like this:
list the current directory
Rename a file
Remove a file
exit
when you executed that some commands like "ls -la $currentdirectory"
which will show almost all the information of the current directory.
SO: if the user does not have permission to do that, (the user doesn't have permission to "LS" that directory .
what command can check the permission?
How to produce an error message if that user does not have the permission?
Cheers
hope to get that answer.
You don't need any separate command to figure out permissions on a directory/file. ls itself will output an error kinda message.
For example, I take away all permissions from everyone,
chmod 000 some_folder
ls some_folder/
ls: some_folder/: The file access permissions do not allow the specified action.
Most commands in Unix like systems will automatically error out with an error message if they don't have sufficient permissions to do their job! The underlying framework will take care of not allowing under-privileged users/apps to run.
grep -i umask ~/.profile /etc/profile