I want to chmod a directory to prevent any files inside that directory from being deleted or modified without my permission.
How can I achieve that, my directory is set to 777 now which I think is a issue. Could other users access and delete my file without permission if I set the permissions to 777? What permission should I set so that?
I want to be the only one who can write to my own directory, others should only be able to read my file.
Yes, with 777, anybody could delete files from the directory.
You should run chmod 0755 yourdir or chmod og-w yourdir.
You can see the contents (read), add or remove files (write) and "pass through" the folder (execute)
Members of the owning group and other users can see the contents of the folder (read) and "pass through" to child folders (execute). They cannot add or remote files (write).
This guide is a good discussion of *nix directory permissions.
Rather than thinking about it in terms of numeric codes, perhaps it's easier to use the symbolic names for permissions. For example, to remove the ability for "others" to "write" your files:
chmod o-w FILE...
You may also want g-w if you do not want members of your Unix group to write your files.
The removal of write (w) permissions is the same as "clearing bit 2" in the mode, so 7 becomes 5, but this is hard for most normal people to remember, and you don't entirely need to.
Related
I am trying to deny all users from being able to delete a folder (as well as its contents, if possible).
What I currently have is not working.
icacls pics /deny Everyone:(OI)(CI)(DE)
Using the above line neither protects the folder nor its content as I can still delete the folder and all files within it.
I think i found a solution:
icacls pics /deny Everyone:(OI)(CI)(DE,DC)
which denies the specific rights to delete (DE) and to delete childs (DC).
To get this language independent use *S-1-1-0 instead of Everyone. (see Well-Known SIDs)
You might still be able to remove the folder if it happens to be empty. If that's a problem, consider setting the read-only flag, e.g., attrib +r pics, and then denying (WA) so it can't be changed (credit to Harry Johnston)
To prevent deletion of a file, you need deny the Delete permission on the file and deny Delete Child permission (a.k.a. "Delete subfolders and files") on the containing folder. Both must not be allowed in order to truly prevent deletion.
In other words, Windows allows deleting a file if either or both of the permissions are granted.
The above part of the answer should be enough if you are permitted to change permissions of the containing folder, otherwise, there are tricks that can prevent your folder from being deleted (all experimented by me).
You can create a (hidden) dummy file within the folder, and prevent deletion on that file (using access control again).
All delete actions, whether through Windows Explorer GUI or DEL or RMDIR command, cannot delete a read-only file or folder directly, what the aforementioned commands do is to try removing the read-only attribute on the file before doing the delete operation. So setting read-only attribute on a folder while denying Write Attributes (WA) permission will effectively prevent the folder from being deleted.
Here is a batch script example of combining two tricks together:
ECHO.>"myfolder\dummy"
REM Technically R is sufficient to prevent deletion,
REM but it wouldn't hurt to add H and S attributes.
attrib +R +H +S "myfolder\dummy"
REM Deny permissions on dummy file.
REM Hint: S-1-1-0 means Everyone; S-1-5-7 means Anonymous Logon group
icacls "myfolder\dummy" /deny *S-1-1-0:^(DE,WA^) *S-1-5-7:^(DE,WA^)
REM Make folder read-only and deny permissions on it.
attrib +R "myfolder"
icacls "myfolder" /deny *S-1-1-0:^(DE,DC,WA^) *S-1-5-7:^(DE,DC,WA^)
I'm using a Mac. I need to rename a file in the /Library/Application Support/AppName/filename.aiff
This is the system library and not /User/username/Library...
I'm using the rename(old name, new name) function. This function doesn't work (even though it doesn't return an error) if I place the file in the /Library/Application Support/AppName directory but it works properly if I place the file, for example, in /User/username/Documents/filename.aiff.
I don't know what the problem is. Any help would be appreciated. Thanks!
You don't own the directory you're trying to move files into:
/Users/Username/... is a user owned directory, so you're allowed to manipulate files there.
/Library is not a user owned directory.
In order to manipulate files in a non-user owned directory you would need elevated permissions. Instead of using /Library you should be using ~/Library, which is the user owned directory. ~/Library is the shorthand name for /Users/Username/Library.
If the rename is working fine in other path means the problem should be related to permission to access file or with the path searched for file.
In my program, I have to make a file hidden in order to avoid removal or modification of the file.
PATH=/etc/
NAME = file
Is there a function in C that will allow me to do that?
You can just add a . to the front of the file name. Having said that if your goal is to not allow modification of the file change the permissions to something that can't be modified. Something like:
chmod 444 fileName
First: others argue with security arguments here. For those: Hidden files have nothing to do with security nor will it prevent somebody from deleting a file if he has propper permission and wants to do that.
Hidden means only that tools like ls, bash globs or a graphical file managers will not display the files with their default settings. This can be useful to prevent from accidents (see explanation below) or just to keep directory listings more clean. You may try the commands ls -l $HOME and ls -al $HOME in order to see the differences.
On GNU/Linux systems and UNIXs it is by convention that files which's name begins with a dot . will not being displayed by default meaning they are hidden. Like $HOME/.bashrc
Solution: Prefix the file name with a dot:
.file
About accidents. Hiding a file can prevent you from accidently removing it when you type something like:
rm *
The glob above will not list hidden files so they won't get deleted.
In LINUX Hidden file are start with .(DOT)
if you create files with starting .(DOT), those files are hidden.
You can use chmod to set permissions to the file.
if you set only read only then those cannot be modified in program
chmod 444 filename
if you want to use this from C-language use system() function to execute this command
if You use simple ls -alF you can see those files.
the below files are hidden files In LINUX
-rw------- 1 root root 27671 Sep 17 11:40 .bash_history
-rw-r--r-- 1 root root 3512 Jul 23 16:30 .bashrc
There are no hidden files on Linux. Some tools don't show files starting with . as others already mentioned.
Anyway, you can experiment with putting control characters like new-line into the filename. See Control characters in filenames are a terrible idea:
Some control characters, particularly the escape (ESC) character, can cause all sorts of display problems, including security problems. Terminals (like xterm, gnome-terminal, the Linux console, etc.) implement control sequences. Most software developers don’t understand that merely displaying filenames can cause security problems if they can contain control characters. The GNU ls program tries to protect users from this effect by default (see the -N option), but many people display filenames without getting filtered by ls — and the problem returns. H. D. Moore’s “Terminal Emulator Security Issues” (2003) summarizes some of the security issues; modern terminal emulators try to disable the most dangerous ones, but they can still cause trouble. A filename with embedded control characters can (when displayed) cause function keys to be renamed, set X atoms, change displays in misleading ways, and so on. To counter this, some programs modify control characters (such as find and ls) — making it even harder to correctly handle files with such names.
Your requirements are a bit vague: the program creates a file, wants to prevent its removal or modification. Do you expect other users (of your program? in general?) to be able to read it, but not find it easily, or modify or delete it?
Keep in mind that Unix-like systems don't really do hidden when the resource involved needs to remain visible (readable, presumably), as others have noted. Prepending a '.' to a file name helps in some important contexts (default ls(1) behavior and shell * globbing in particular) but only goes so far. But a few techniques might help obscure what and where your app is saving things, if that matters.
Consider two users doing some shell commands like the following in a directory with its sticky bit set (say /tmp). (Sorry to not write C, but I think the scenario is easier to demonstrate out in the shell.)
As Bob:
$ umask 066
$ mkdir /tmp/.hidden
$ umask 022
$ echo xyzzy > /tmp/.hidden/mysecret.txt
$ ls -la /tmp/.hidden
total 28
drwx--x--x 2 bob users 4096 Sep 17 11:19 .
drwxrwxrwt 27 root root 20480 Sep 17 11:26 ..
-rw-r--r-- 1 bob users 6 Sep 17 11:19 mysecret.txt
As Alice. Notice that attempts to search in /tmp/.hidden fail, but if she knows the name of a file in a directory with only execute but not read permissions set, she can read the file. She can't do much to mess with /tmp/.hidden, once it's properly created. If she'd been forced to guess the name of the secret file, that could also be a challenge depending on how the name is created.
$ ls /tmp | grep hidden
$ ls -a /tmp | grep hidden
.hidden
$ file /tmp/.hidden
/tmp/.hidden: directory
$ ls /tmp/.hidden
ls: cannot open directory /tmp/.hidden: Permission denied
$ echo /tmp/.hidden/*
/tmp/.hidden/*
$ file /tmp/.hidden/mysecret.txt
/tmp/.hidden/mysecret.txt: ASCII text
$ cat /tmp/.hidden/mysecret.txt
xyzzy
$ rm -f /tmp/.hidden/mysecret.txt
rm: cannot remove '/tmp/.hidden/mysecret.txt': Permission denied
$ mv /tmp/.hidden /tmp/Hidden_No_More
mv: cannot move '/tmp/.hidden' to '/tmp/Hidden_No_More': Operation not permitted
$ rm -rf /tmp/.hidden
rm: cannot remove '/tmp/.hidden': Permission denied
In this scenario, the presence of the hidden directory can be obscured, but ls -a reveals its name. Carefully chosen directory permissions prevent non-root and non-Bob users from listing or altering its contents. The use of a sticky-bit directory like /tmp prevents non-Bobs from renaming or removing the "hidden" directory. Anyone who knows the name of the "secret" file within the hidden directory can read it. But only Bob and root can change these "secret" files or the "hidden" directory.
You can do all the above in a C program; equivalents exist as library and system calls - see things like chmod(2), mkdtemp(3), umask(2), the mode argument to open(2), etc.
If you use a kernel >= 3.11, you might want to try the O_TMPFILE-flag. This kernel have been released on the 14.09.2013. Debian Jessie uses Kernel 3.16. so this feature should be available on all recent popular distributions.
The news about this sounds promising. The file will be unreachable from the outside. No other process or may access this file .. neither read nor write. But the file will be lost as soon as the handle gets closed. Or link it to a regular file. But then, it will be accessible as any other file.
If this is not an option for you (e.g. your file needs to be persistent): bad luck. There is no real "hidden" file in linux. You can hide your persistent files as secure as files on windows with the hidden attribute: prepend the name with a dot. As stated by others: ls -a will show them nevertheless.
Also, you can create a user specifically for your use and make the file read- and writable only for this user or put it in a folder, where only your user have rw-access. Other users may see this file but wont be able to access it. But if root comes along and want to look into it, you have lost.
Sure,you have to add '.' before filename and your file wouldn't be seen by user(except user will turn the hidden files show option on). You could change the attrybutes (chmod) to 755 and only user could rwx and others could rx.
hek2mgl - partially yes - it has. Try to remove via rm -rf * manner all of directory content. That's why for example .htaccess is hidden.
I'm currently compiling different PHP versions and want to delete some rubbish folders.
I got a folder called "php-5.4.7-src" which i want to delete but when I do
$ rm -Rf php-5.4.7-src
there always pops up
rm: cannot remove directory php-5.4.7-src/ext/standard/tests/general_functions: File exists
rm: cannot remove directory php-5.4.7-src/ext/standard/tests: File exists
rm: cannot remove directory php-5.4.7-src/ext/standard: File exists
rm: cannot remove directory php-5.4.7-src/ext: File exists
rm: cannot remove directory php-5.4.7-src: File exists
So I did
$ find .
and
$ find . -type f
and there just pop up the folders above, no files exist.
I am also owner of all folders and I tried to delete them as root too.
How can I delete files which do not exist?
I realize that this does not answer your question but just a small matter of style that may save you headaches in the future. If you ever have to move your scripts to another flavour of UNIX there's a chance they will break. The traditional flag for doing a recursive delete is -r, not -R. Saves you having to push the shift key too :)
Now on to what may answer your question. I know you said you checked for running processes but that is the only way that an inode can be kept open, and only an open inode will keep a hierarchy from being removed. There are other processes such as updated that frequently run on systems that may have been crawling through your directories at the time. One thing you may try is to execute sync to ensure that all pending writes have been flushed.
Something is holding the directory open. You may also want to try lsof +D php-5.4.7-src to see exactly what.
In our FreeBSD-environment where we have one server that acts as a file-server, we have a problem that our system administrator says can not be fixed.
All our files resides in a directory and we all have access to that directory, its sub-directories and files. The problem is that once a user in our group creates a file or directory, we have to chmod that directory or file to change the rights so that others in our group can access, read, write and delete. These are not files or sub-directories inside our home-directories, but in a directory where we are supposed to work with them on a daily basis.
Finding it difficult to believe that there is no good solution, I would request that someone assist me with a solution.
I think what you want is a setgid bit on the directories and umask. Then newly created there files and directories will have proper group and proper permissions to let others read abd write them.
find /your-files-are-rooted-here -type d -print0 | xargs -0 chmod ug+rw,g+s
and set umask to 002 (or whatever is appropriate). And, of course, you may want to fix permissions for existing files (the command above only takes care of directories).
One place to but the umask setting is "/etc/bashrc". Find "umask". Change "umask = 022" to "umask = 002". After doing this, when a new file created, every one in the same group with the file owner can write in this new file.
Note that this only works for files created from the shell, specifically bash.