I want to read the content of a file at a known path in a different user home.
The file is world readable, and so are all the sub directories.
How ever, when I try to open it, I get a "permission denied"
cat /home/rails/current/tmp/pids/delayed_job.pid
cat: /home/rails/current/tmp/pids/delayed_job.pid: Permission denied
With
rails#tatoo:~/current/tmp/pids$ ls -l
total 4
-rw-r--r-- 1 rails rails 6 Dec 30 10:09 delayed_job.pid
What could I be missing ?
To be able to read a file, not only you need to have read access to the file r but you also need to have access right x for every directory in that file path up to the root directory.
As execution right doesn't make sense for a directory, the x bit is used to grant access rights for it.
Have a look here for a detailed explanation about directory permissions.
Related
I am trying to set adb path so I can access it easily from any directory.To set the path I am trying to edit the .bash_profile to insert the following line :
export PATH=$PATH:/Users/anshulsinghla/Library/Android/sdk/platform-tools/
Command I use to open file: open -e .bash_profile
But I always get a prompt saying "You Don't own the file .bash_profile and don't have permission to write to it. You can duplicate this document and edit the duplicate.Only the duplicate will include your changes".
I tried checking the who is the owner and what permission do they have with following command :
ls -la ~ | grep bash
Output:
-rw------- 1 anshulsinghla staff 6820 Jun 22 10:09 .bash_history
-rw-r--r-- 1 anshulsinghla staff 659 Jun 22 10:11 .bash_profile
It clearly shows I am the owner of the file and I do have read/write permissions but why it never let me edit the file, someone please help me.
Thanks
All the diagnostics have been using ~, so try:
open -e ~/.bash_profile
What did we learn from this? When diagnosing an error, always use exactly the same filename as was used in the error.
The original command did not try to edit .bash_profile in your home directory, yet in the comments everyone was looking at your home directory.
I created this simple script to allow the user to remove files created by the web server in his home directory without giving him "su". Both scripts are set with "chmod 4750".
The craziest thing is that they DID work and now they don't. Here's the scripts:
#!/bin/bash
# Ask for directory to delete
echo "Enter the file or directory you would like to delete, the assumed path is /home/user"
read DIRECTORY
rm -rf /home/user/"$DIRECTORY"
echo "Deleting /home/user/$DIRECTORY ..."
exit 0
2:
#!/bin/bash
# Reset permissions
echo "Resetting the ownership of the contents of /home/user to user."
chown -R user /home/user
exit 0
I will make them a little more advanced and work for multiple users but right now I cannot even get the simple version to work. It works when run as root of course. It used to work when run as user 'user' but now it doesn't. I get this:
user#dev:/home/user$ delete.sh
Enter the file or directory you would like to delete, the assumed path is /home/user/[your input]
test-dir
rm: cannot remove ‘/home/user/test-dir/test-file’: Permission denied
Deleting /home/user/test-dir ...
and
chown: changing ownership of ‘/home/user/test-dir’: Operation not permitted
What can possibly be the problem?
-rwsr-x--- 1 root user 291 Nov 6 05:23 delete.sh
-rwsr-x--- 1 root user 177 Nov 6 05:45 perms.sh
There is a pretty comprehansive answer at https://unix.stackexchange.com/questions/364/allow-setuid-on-shell-scripts
Bottom line is that there are two main points against it:
A race condition between when the Kernel opens the file to find which interpreter it should execute and when the interpreter opens the file to read the script.
Shell scripts which execute many external programs without proper checks can be fooled into executing the wrong program (e.g. using malicious PATH), or expand variables in a broken way (e.g. having white space in variable values), and generally it has less control on how well the external programs it executes handle the input.
Historically, there was a famous bug in the original Bourne shell (at least on 4.2BSD, which is where I saw this in action) which allowed anyone to get interactive root shell by creating a symlink called -i to a suid shell script. That's possibly the original trigger for this being prohibited.
EDIT: To answer "How do I fix it" - configure sudo to allow users to execute only these scripts as user root, and perhaps use a trick like in https://stackoverflow.com/a/4598126/164137 to find the original user's name and force operation on their own home directory, instead of letting them pass in any arbitrary input (i.e. in their current state, nothing in the scripts you include in your question prevents user1 from executing the scripts and passing them users2's directory, or any directory for that matter)
I'm new to mac with not familiar on terminal command, i put the dvtcolorconvert.rb file on root directory of my volume, this ruby script can converting xcode 3 themes into xcode 4 themes format, which is xxxxxxxx.dvtcolortheme format.
Then run the script /dvtcolorconvert.rb ~/Themes/ObsidianCode.xccolortheme on terminal, but it's always prompt "Permission denied".
what's wrong with this? Anybody can help me solve this problem? Thanks.
Did you give yourself the rights to execute the script?
The following command as super user will do this for you:
sudo chmod 755 'filename'
For details you should read the man page of chmod.
Please read the whole answer before attempting to run with sudo
Try running sudo /dvtcolorconvert.rb ~/Themes/ObsidianCode.xccolortheme
The sudo command executes the commands which follow it with 'superuser' or 'root' privileges. This should allow you to execute almost anything from the command line. That said, DON'T DO THIS! If you are running a script on your computer and don't need it to access core components of your operating system (I'm guessing you're not since you are invoking the script on something inside your home directory (~/)), then it should be running from your home directory, ie:
~/dvtcolorconvert.rb ~/Themes/ObsidianCode.xccolortheme
Move it to ~/ or a sub directory and execute from there. You should never have permission issues there and there wont be a risk of it accessing or modifying anything critical to your OS.
If you are still having problems you can check the permissions on the file by running ls -l while in the same directory as the ruby script. You will get something like this:
$ ls -l
total 13
drwxr-xr-x 4 or019268 Administ 12288 Apr 10 18:14 TestWizard
drwxr-xr-x 4 or019268 Administ 4096 Aug 27 12:41 Wizard.Controls
drwxr-xr-x 5 or019268 Administ 8192 Sep 5 00:03 Wizard.UI
-rw-r--r-- 1 or019268 Administ 1375 Sep 5 00:03 readme.txt
You will notice that the readme.txt file says -rw-r--r-- on the left. This shows the permissions for that file. The 9 characters from the right can be split into groups of 3 characters of 'rwx' (read, write, execute). If I want to add execute rights to this file I would execute chmod 755 readme.txt and that permissions portion would become rwxr-xr-x. I can now execute this file if I want to by running ./readme.txt (./ tells the bash to look in the current directory for the intended command rather that search the $PATH variable).
schluchc alludes to looking at the man page for chmod, do this by running man chmod. This is the best way to get documentation on a given command, man <command>
In my case, I had made a stupid typo in the shebang.
So in case someone else on with fat fingers stumbles across this question:
Whoops: #!/usr/local/bin ruby
I meant to write: #!/usr/bin/env ruby
The vague error ZSH gives sent me down the wrong path:
ZSH: zsh: permission denied: ./foo.rb
Bash: bash: ./foo.rb: /usr/local/bin: bad interpreter: Permission denied
You should run the script as 'superuser', just add 'sudo' in front of the command and type your password when prompted.
So try:
sudo /dvtcolorconvert.rb ~/Themes/ObsidianCode.xccolortheme
If this doesn't work, try adapting the permissions:
sudo chmod 755 /dvtcolorconvert.rb
sudo chmod 755 ~/Themes/ObsidianCode.xccolortheme
To run in the administrator mode in mac
sudo su
use source before file name,,
like my file which i want to run from terminal is ./jay/bin/activate
so i used command "source ./jay/bin/activate"
Check the permissions on your Ruby script (may not have execute permission), your theme file and directory (in case it can't read the theme or tries to create other themes in there), and the directory you're in when you run the script (in case it makes temporary files in the current directory rather then /tmp).
Any one of them could be causing you grief.
I'm trying to p4 sync, but I got a "Can't clobber writable file" error. So, I removed the writable permission, but now I get this error:
$ ls -l file.txt
-r--r--r-- 1 myusername admin 1.0K Jan 1 00:00 file.txt
$ p4 sync file.txt
//the/depot/directory/file.txt#5 - deleted as /my/local/workspace/directory/file.txt
unlink: /my/local/workspace/directory/file.txt: Permission denied
I am logged in as myusername. Why am I getting permission denied?
Instead of changing file permissions, you can do a p4 sync -f. But take care, it can be dangerous:
Force the sync. Perforce performs the sync even if the client workspace already has the file at the specified revision. If the file is writable, it is overwritten.
This option does not affect open files, but it does override the noclobber client option.
So make sure to commit your work before doing it.
Why am I getting permission denied?
Because you just took away your own write permission. That means you no longer have permission to write to the file. Which means p4, acting on your behalf, no longer has permission to write to the file. Which means that when p4, acting on your behalf, asks for permission to write to the file, it's denied. Which means p4 says "Permission denied".
What else did you expect to happen?
The reason p4 sync is complaining is that you appear to have a file that you've checked out (and therefore possibly made changes to) and it doesn't know about it, so it refuses to just overwrite your hard work. You should manually revert the file, if that's what you want to do.
Perforce keeps track of what state it expects your files to be in. If it left a file with non-writable access, and expects it to still be in that state, it will attempt to chmod it before overwriting it. But if it thinks the file should be writable, it will just open it and try to write it. The fact that a chmod would succeed is irrelevant if p4 never calls it.
At any rate, the solution is to explicitly revert the file, delete it and re-pull it, etc.
I have sh script which copies all files from some folder to some host.
scp -r -i PATH_TO_SSH_KEY SOURCE_FOLDER/* SERVER:TARGET_DIR
When I run this script I get the following result:
Cygwin lists all files in my SOURCE_FOLDER and says that these files were not found! "No such file or directory". That looks odd. I have checked that all files in that folder have -rw-r--r-- permissions. I have tried to set higher permissions, but I cannot keep them because the files are regenerated each time I run this script, so they are always like this.
The questions are:
1) which permissions should have files to be transferred by scp?
2) can I setup a folder in a way that all files inside are always created with some predefined permissions?
3) in case my guess about permissions falls - what else can be a reason of this behaviour?
Seems to work for me, but I work in Linux. Not 100% familiar with cygwin. To answer your permissions questions:
1) The files should be writable. If they're owned by root, well, change the group or use sudo. I'll explain the next step how I'd handle it.
2) Yes, you'll want to use umask to achieve this. I wouldn't do remote root user copy or 777 permissions. You'd want to assign a umask for that directory and assign certain groups to it. A 002 umask means that all people part of the group in that directory have read write access. The next two commands then add a group to that directory, and the default group for files. The following is an example of the syntax:
umask 002 <dir>
chgrp <group> <dir>
chmod g+s <dir>
3) Syntax... but I'm guessing permissions. Check permissions of both target and source server.
I hope this was helpful!
umask reference:
http://man7.org/linux/man-pages/man2/umask.2.html
cheers!