When I tried to simulate the permission system under Linux, some strange things came about.
I created a directory 'main' by user 'normal', and created directory 'aha' which permission is 700 using root.
so the owner of 'main' is 'normal', if the permission is 755, I can delete 'aha' just using 'normal' user although its owner is root.
but when i put a file in 'aha', everything is changed. I can not remove 'aha' due to there's still a file in it.
so, my question is, since 'aha' is 700 by root, how can 'normal' know it's empty or not?
My further question is : what does read permission of a directory really mean?
Think of a UNIX directory as a drawer of index cards in the library catalog.
In order to know what books there are, you need read permission on the "drawer". In order to create or remove new "books", you need write permissions (which give you ability to put new cards, or remove existing cards from the drawer). In order to "traverse" the directory to a lower level "sub-drawer", you need execute permission on the drawer itself.
If you already know that book /foo/bar/baz exists, you don't need read permissions on /, /foo or /foo/bar, but you do need execute permissions on all of them.
A given book could be referenced by multiple "cards" in the same or separate "drawer" (that's hard links).
A "card" can reference another card (that's symlinks). Symlinks could became "dangling" (if the other card is removed).
When a book is not referenced by any card in any of the drawers, it "evaporates" from the library.
since 'aha' is 700 by root, how can 'normal' know it's empty or not
Well, one way is to try to remove it. If you succeed, it must have been empty. If it was not empty, "normal" can't find out anymore than that, since "normal" can't read the directory, and therefore can't find how many cards are in that "drawer", or what they are called.
Update:
why do you need execute permissions to traverse a directory.
Because that's the definition of the eXecutable bit for directories. Since you can't reasonably execute a directory, that bit would be wasted otherwise. No, the . and .. files have nothing to to do with the execute bit.
very basically a file/dir permission of 700 is not seven hundred but actually
owner = 7
group = 0
everyone = 0
the numbers pertain to a permission level
0 = no permission
1 = allow to execute (run file or access directory)
2 = allow to write (manipulate)
4 = allow to read (see)
you add the permissions levels up to assign more then one permission for example
$ chmod 754 foo
gives full access to the owner (1+2+4), execute 'n' read to the group (1+4), and read to everyone (4) look at
http://www.linuxclues.com/articles/16.htm
http://www.tuxfiles.org/linuxhelp/filepermissions.html
for more info
Related
There are tons of posts on the net saying that write permission on directory allows affected user to create/remove/rename files in that directory, but I found that it actually could not be done without execute permission set. I tried calling open/fopen/remove/rename, but without exception, they all failed.
There should be something I missed or something I misunderstood. There are some explanation that operations on directory usually involves with file operation. If it was right, I wonder what operation is involved. If directory maintains mappings from filename to inode, it seems no reason that file operation is involved when renaming.
If unexpected file operation is involved, is it possible to manipulate directory directly, bypassing such operations?
You are right, the net is full of wrong things and especially for unix file permission rules. The first links I found with a common search engine were all wrong. Very interesting!
What file permissions on directories means:
x you have "access" to the files in this directory which means you can use them. If you do not have read access but access rights, you can work with a file which you know but you can't see!
mkdir one
touch one/x.h
chmod -r one
ls one // fails!
cat one/x.h // works!
and write permission is used for changing the content of the directory. So adding and removing files from the dir is only possible if you have write permission on that dir!
Because it is impossible to read/write/execute a file which is inside a dir which you can't access, you always need access rights for the dir to work with the files inside.
Sounds a bit strange, but is simply implemented that way.
Is it possible to open a file knowing its inode?
ls -i /tmp/test/test.txt
529965 /tmp/test/test.txt
I can provide path, inode (above 529965) and I am looking to get in return a file descriptor.
This is not possible because it would open a loophole in the access control rules. Whether you can open a file depends not only on its own access permission bits, but on the permission bits of every containing directory. (For instance, in your example, if test.txt were mode 644 but the containing directory test were mode 700, then only root and the owner of test could open test.txt.) Inode numbers only identify the file, not the containing directories (it's possible for a file to be in more than one directory; read up on "hard links") so the kernel cannot perform a complete set of access control checks with only an inode number.
(Some Unix implementations have offered nonstandard root-only APIs to open a file by inode number, bypassing some of the access-control rules, but if current Linux has such an API, I don't know about it.)
Not exactly what you are asking, but (as hinted by zwol) both Linux and NetBSD/FreeBSD provide the ability to open files using previously created “handles”: These are inode-like persistent names that identify a file on a file system.
On *BSD (getfh and fhopen) using this is as simple as:
#include <sys/param.h>
#include <sys/mount.h>
fhandle_t file_handle;
getfh("<file_path>", &file_handle); // Or `getfhat` for the *at-style API
// … possibly save handle as bytes somewhere and recreate it some time later …
int fd = fhopen(&file_handle, O_RDWR);
The last call requiring the caller to be root however.
The Linux name_to_handle_at and open_by_handle_at system calls are similar, but a lot more explicit and require the caller to keep track of the relevant file system mount IDs/UUIDs themselves, so I'll humbly link to the detailed example in the manpage instead. Beware, that the example is not complete if you are looking to persist the handles across reboots; one has to convert the received mount ID to a persistent filesystem identifier, such as a filesystem UUID, and convert that back to a mount ID later on. In essence they do the same however. And just like on *BSD using the later system call requires elevated privileges (CAP_DAC_READ_SEARCH to be exact).
I have a file that i want to add to sourcecontrol on linux using cleartool .
I've followed the IBM documentation for this, i've tried this:
cleartool mkelem testScript.sh
I got an error: Can't modify directory "." because it is not checked out.
I also would like to know how can i checkout/checkin files or directories and setting activities.
You need to checkout the parent folder first.
cd /path/to/file/
cleartool mkact newfile
cleartool checkout -c "add file" .
cleartool mkelem testScript.sh
cleartool checkin -nc
The cleartool mkact would work if you are in an UCM view.
It will create and set a new activity, which will record the files and folder you will modify.
Here, the new activity newFile will record the new version of the parent folder, as well as the version 0 and 1 of the file.
You should create separate questions for .. separate questions...
Going back to the original - the reason why it isn't working is, as VonC has pointed out, you haven't checked out the parent of the file. Remember, when you run "cleartool mkelem", you are about to modify the contents of the parent directory (. in this case) by adding a new "pointer" to the element you're now creating. As with everything else in clearcase, when you want to modify the contents of an element, you have to check it out first.
One of ClearCase's greatest strength (and hardest to wrap one's head around) is the concept of an "element", IMO. "Everything" behaves similarly with an element. Making any change to an "element" (file or directory) means you have to check it out first to make that change.
In the case of a file, that's easy to grasp - you're just editing lines in a file. For a directory, it's almost as easy - you can think of a directory as just a list of pointers to data blobs. We make the name of the blob something convenient we can remember (like foo.java or myapplication.cc or README.md). But we can also change the name of the pointer (even though it points to the same data blob) by renaming a file. We can remove the pointer to the blob without impacting the blob itself by using "rmname". That's essentially what "rmname" does.
In ClearCases' case, the mkelem command is a little bit special - it creates the initial datablob, and adds a pointer to that datablob in the current directory (kind of does 2 things at once).
I want to make certain folders read-only for the developers while some subfolders in that folder as write also.
For example, consider the folder structure:
Meeting/Jan/DevInfo/
Meeting/Feb/DevInfo/
Meeting/March/DevInfo/
Meeting/April/DevInfo/
Meeting/May/DevInfo/
I want the developers to have read permission to //Meeting/ but write permission to //Meeting/.../DevInfo/...
Can I use the following code?
read group developers * //Meeting/...
write group developers * //Meeting/.../DevInfo/...
I think it should be correct, but visual in P4 shows that the whole structure of //Meeting/ is write-allowed for developers.
Change the write access line to:
write group developers * //Meeting/*/DevInfo/...
The * character means "all files within the Meeting directory, excluding subdirectories".
The ... entry that you had before means "all files and subdirectories under //Meeting", so it overrode the following DevInfo/... section.
Try running the following to check what the protection levels are:
p4 protects //Meeting/...
My system administrators advice me to be careful when setting access control to files and directories. He gave me an example and I got confused, here it is:
a file with protection mode 644 (octal) contained in a directory with protection mode 730.
so it means:
File: 110 100 100 (owner, group, other: rw- r-- r--)
Directory: 111 011 000 (owner, group, other: rwx -wx ---)
How can file be compromised in this case?
It depends on what you mean by 'compromise' and it depends on who belongs to the group.
The directory permissions are critical. Since members of the group can access the directory ('x') and can modify the directory ('w'), even though they cannot list the directory (no 'r'), it means that if a member of the group knows the name of the file, that person can also remove it because removing a file requires permission to write to the directory - the file permissions are immaterial (even though commands such as 'rm' let you know when you don't have write permission on the file, that is a courtesy, because it doesn't matter to the 'unlink()' system call).
So, a member of your group (or, more precisely, a member of the group to which the directory belongs) can remove the file if they know its name. They can also read the file if they know its name, and they can create a file of the same name if the original is already missing. It appears from the file permissions that being able to read the file is not compromise - you would have denied group read access (and public read access) if that mattered.
Note that although your group members cannot modify the file, because they can delete the file and create a new one with the same name, the result is basically the same as being able to modify the file. One key difference is that you'd know which user did the mischief because that user would own the file. (Well, someone with access to that user ID did the mischief.)
Since the directory can be written to, the file could simply be overwritten with another if the attacker is in the directory owner's group.