I have used chmod 0000 on a directory yet the directory can still be renamed. How can I prevent a user from modifying the name of a directory?
Removing write permission on the parent directory should do the trick.
If you own a file (or directory) you can still perform various operations on it regardless of permissions including mv, rm and chmod. Other users cannot perform these options based on write permissions. If you want to prevent the owner from moving the directory, you can't. The owner can always use chmod on the file. The only solution would be to change the owner of the file or move the file under a write-protected directory that the user does not own.
Related
How can I prevent .git/index from constantly changing its permissions and ownership?
I run ls -al .git/index and see that the file is owned by root.
I change the permissions with sudo chown -R $USER:USER and sudo chmod -R 775 .git
I even tried deleting the lock file with rm -rf .git/index.lock
The permissions update but then a few minutes later they change back to being owned by root and 740 which breaks the git commands I'm attempting.
I set the global git config via Ansible so I'm wondering if that messed something up? Is there a global file I need to modify?
When Git writes the index, the way it does so is to create a new file called .git/index.lock (with O_EXCL), adjusts its permissions according to core.sharedRepository, and then rename it over top. Git does not offer a way to rewrite the file in place.
If this file is being created such that it's being owned by root, then root is creating the file because it's updating the index. That probably means that some process owned by root is modifying the working tree.
If that wasn't your intention, then the best thing to do is find that process and stop it from modifying the working tree. It's not a good idea for multiple users to modify the same working tree, and if your process owned by root is reading files out of the working tree and it's shared with another user, that could lead to a security vulnerability.
If you're certain what you're doing is safe and you want to modify the permissions with which files in the .git directory are created, you can use core.sharedRepository to set them. For example, you could use the value 0664. Note that Git will handle the executable bit automatically, and the index should not be marked executable.
If you want to always use the same group for your repository, you can set the setgid bit on all the directories in the repository and then set their group to the appropriate value. Assuming you also set core.sharedRepository to a value that makes things group writable, you can then modify the repository with any user in that group, and things should work. Note that this may still have security implications if one or more of those users are untrusted or have lower privileges, so you should be careful.
I'm trying to remove all files except read-only ones, but this command removes all of them anyway:
yes n | rm *
Did I do something wrong? If not, why doesn't it work?
For rm to automatically enable -i mode that prompts the user to delete unwritable files, the standard input has to be a terminal (as specified in the man pages).
So, for the command to work correctly the user has to specify the -i option manually:
yes n | rm -i *
After doing so the command works as expected.
In Posix systems, the read-only state of a file does not prevent it from being removed by rm.
You haven't said what your shell is, but perhaps you have an alias to rm that does ask you for confirmation when the file is read-only, and that alias behaves differently when it stdin is part of a pipe.
The problem is you only need write permissions to the folder, not to the files, to remove them:
(From here)
Any attempt to access a file's data requires read permission. Any attempt to modify a file's data requires write permission. Any attempt to execute a file (a program or a script) requires execute permission.
In *nix systems directories are also files and thus use the same permission system as for regular files. Note permissions assigned to a directory are not inherited by the files within that directory.
Because directories are not used in the same way as regular files, the permissions work slightly (but only slightly) differently. An attempt to list the files in a directory requires read permission for the directory, but not on the files within. An attempt to add a file to a directory, delete a file from a directory, or to rename a file, all require write permission for the directory, but (perhaps surprisingly) not for the files within. Execute permission doesn't apply to directories (a directory can't also be a program). But that permission bit is reused for directories for other purposes.
To find files with specific permissions you can use
find -perm <mode>
read more
To remove files found by find you can use
find . -perm 444 -exec /bin/rm {} \;
(mybe slightly different, it depends on files you search and system you have)
more exec examples
Im having trouble in Bash.
I have plain files in a directory on my desktop. I am trying to move them into a subdirectory within that directory using: mv "Filename" /"Directoryname"
However when I use this command, I get an error telling me that the permission was denied.
I am set as the owner of both directories and have should have full permissions. If there is anything I need to provide you to make it easier for you to help me, I will be glad to help.
Try mv filename subDirectoryName/.
By placing / in front of the directory name in a move sequence, you're telling the shell that you would like it to be placed in a high level folder named /folder.
What you want is a sub-directory within your current directory. As you would usually move directories in bash, ../ goes up one directory, and directory/ implies you are moving into a folder that is within your current directory.
i'm trying to make a file removable just by root user In mac 10.10.
i was try this :
chown root <fileName>
but other user can remove it;
any idea?
As an alternative to changing the permissions on the containing directory, you can set the uimmutable flag on the file:
sudo chown root foo
sudo chflags uimmutable foo
Now only root will be able to delete foo. Note, though, that nobody will be able to modify the file, either. Root could remove the uimmutable flag and then modify it, of course, but that opens a window for others to delete it.
The act of removing an entry in a directory modifies the directory, but not the file. (When you remove a file, you are unlinking the name from the file and the link count on the file is decremented. The file itself may not be deleted, but will no longer be accessible by the name that was removed.) In order to ensure that only some process with root privilege can unlink a file, you need to modify the permissions on the directory. So to ensure that no-one but root can delete the file /p/a/t/h/file:
sudo chown root /p/a/t/h # make root the owner of the directory
sudo chmod og-w /p/a/t/h # remove write permissions from other and group
Note that this is less fine grained that you might like and will prevent non-root users from removing or creating any files in /p/a/t/h.
I have a folder with drwxrwxr-x permissions, where the owner is uploading his own files.
I want to upload on that directory a readme file. The owner of the folder shouldn't have the right to delete that file. How I can do that? What rights should I set for the directory & for the file.
There are ways of doing this with ACLs, but the easiest way, if your OS supports it, is to make readme an immutable file. A file with the immutable flag can't be modified, deleted, or renamed, even by the owner or the owner of the containing directory. On Linux, this would be done with sudo chattr +i /path/to/directory/readme. On Linux, not even the owner of a file can remove the immutable flag (well, unless the owner can run a process with the CAP_LINUX_IMMUTABLE capability).
The file should have drwxr--r--, this way only you, the owner of the file, have the ability to delete it.
chmod 744 <file>