Eben King wrote:
> On Sat, 29 Oct 2005, Paul M Foster wrote:
>
>
>> On Sat, Oct 29, 2005 at 12:38:34AM -0400, Eben King wrote:
>>
>>
>>> On Fri, 28 Oct 2005, Sick Twist wrote:
>>>
>>>
>>>> Having used Linux for some time, I thought I had a clear understanding of
>>>> how file permissions work. However, I have no idea why I am able to
>>>>
>>> delete a
>>>
>>>> file owned by someone else for which I do not have write permission:
>>>>
>>> Whether you can delete a file depends on having write permission in its
>>> directory, not on the permissions of the file itself. If you want to
>>> truncate it and keep everything else -- inode, permissions, etc. -- the same
>>> (e.g. "cat /dev/null > file"), you need to have write permission on the
>>> file.
>>>
>> Oh now you've gone and messed everything up. I had this all worked out,
>> too, and now you've wrecked my understanding. ;-}
>>
>> If the permissions on the file itself don't have anything to do with
>> whether one can write to or delete the file in a given directory,
>>
>
> They do affect whether you can write to it (that'd be modifying the file
> data), but not whether you can delete it.
>
> * What follows is my understanding. I welcome corrections. *
>
> A directory is just another file, really. It's at something like
>
> <file name>\0<file type>\0<inode>\0<other metadata>\0
>
> so to delete a file involves deleting that line, thus modifying the
> directory, not the file itself. Separators are not needed after fixed-width
> fields, so some of that is wrong. Some extra stuff is done for files with
> hard links, but I'm not sure what. I think there must be a list of hard
> link locations and a link count, and when one reference to a file is
> deleted, all link counts are decremented. But that sounds Byzantine; there
> must be a simplification.
>
Everything in a Unix filesystem is an "inode". Files are inodes as well
as directories.
As Eben pointed out, directories _are_ files. They're specially
formatted binary files.
Programatically, you use opendir()/readdir() to read one dirent
structure at a time from that binary file that is a directory. Try "man
readdir", and you'll see the dirent structure:
struct dirent {
long d_ino; /* inode number */
off_t d_off; /* offset to the next
dirent */
unsigned short d_reclen;/* length of this record */
unsigned char d_type; /* type of file */
char d_name[256]; /* filename */
};
This dirent structure is how all entries are represented in a directory,
from a userspace perspective.
Most Unix commands handle the return result code of open() of EISDIR to
print "Is a directory" if you try to do an operation like cat, dd, or
otherwise attempt to use a directory as a file directly.
$ cat /etc
cat: /etc: Is a directory
$ dd if=/etc
dd: reading `/etc': Is a directory
$ od /etc
od: /etc: read error: Is a directory
If you use the open() call with O_DIRECTORY, however, you can read the
directory as a file with read() (this is what opendir() does).
Once you start to think of directories as glorified files, the
permissions start to make sense.
The permissions of a directory state what can be done to the things
contained within that directory.
A directory contains a list of files, their types, and their permissions.
Every file has an inode that represents the actual storage of the file
on the filesystem - directories are no different.
As a directory itself is just a glorified "special" file, it is treated
as just another entry in a parent directory, with an associated inode.
The permissions on a file, or a directory, state what you can do to the
contents of the inode.
The contents of a directory are just filenames (plus permissions, inode,
other dirent metadata).
When you change the permissions on a directory you give the ability to
rename or delete files in that directory.
When you change the permissions on a file you give the ability to read
or write data blocks to that file.
- Ian C. Blenke <ian@blenke.com> http://ian.blenke.com
-----------------------------------------------------------------------
This list is provided as an unmoderated internet service by Networked
Knowledge Systems (NKS). Views and opinions expressed in messages
posted are those of the author and do not necessarily reflect the
official policy or position of NKS or any of its employees.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 18:56:25 EDT