Paul M Foster wrote:
> On Sat, Oct 29, 2005 at 05:58:08PM -0400, Ian C. Blenke wrote:
>
>
>> 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:
>>>>>
>>>>>
>
> <snipation>
>
> Excellent exposition, but it begs the question. Obviously, when you
> delete or write to a file in a directory, you're doing two things:
> affecting the file itself, and the directory in which it's written
> (which in itself is a glorified file). Given:
>
> drwxr-xr-x paulf paulf /home/paulf
> -rwx------ bob bob /home/paulf/bobsfile
>
> it makes sense to me that, as paulf, I'd need rwx permissions in the
> directory to delete or write to bobsfile. However, it doesn't make sense
> that I could delete bobsfile. The permissions on the directory would
> allow it, but the permissions on bobsfile should deny it. I would have
> assumed that the logic would be:
>
You need execute permission to the directory to change directory into it.
You need read permission to a directory to see the files in it.
You need write permission to the directory to delete or rename a file in
it (or change the permissions, or other metadata).
You need write permission to the file to write to it (the permission of
the directory the file is in is irrelevant to whether you can write to a
file, barring the lack of the execute bit to open the file in that
directory in the first place).
> But that appears to not be the case. It would appear from the logic in
> this thread that the actual file permissions (and ownership) are simply
> ignored. But then the question becomes: why have individual file
> permissions at all (on regular files)?
>
That is correct. If a user has write permissions to a directory, they
can rename/delete the files within it regardless of the permissions on
the files themselves.
Individual file permissions are there to lock down permissions to modify
the files.
> So if the above isn't the logic, what is?
>
You only need execute permission to the parent directories to open a
file. You don't need read or write access to do this.
You _do_ need write permission to a file to write to it. You also need
read permission to a file if you wish to read from it.
If you want to rename or delete a file, that's not an operation on the
actual file inode, that's an operation on the directory containing a
filename (the directory inode containing the file that links to the
actual file inode).
Hardlinks are nothing more than directory entries that link to a common
inode on the same filesystem.
Perhaps a better question is: what are you trying to do? We can work up
some use cases of what permissions should be to "lock down" a directory,
or to a file within it.
Sometimes it takes a bit of group magic, or setuid/setgid logic, to lock
things down correctly as well.
Then there are hacks like the sticky bit on directories, used for things
like /tmp which require users to be able to create files but _not delete
or rename_ files created by other users.
Confused yet? ;)
- 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:57:43 EDT