lkml.org 
[lkml]   [1999]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Odd filesystem permission handling


On Thu, 17 Jun 1999, Mike A. Harris wrote:

> Logged in as user "mharris" and in my home dir, I had a dir
> called "down" owned by root.root with perms 755.
>
> This dir had files in it.
>
> As "mharris" I tried to chown the dir to mharris.mharris, and I
> got permission denied. I then tried "rm -rf down/" also as
> mharris, and it successfully let me remove the directory.

What kernel it was?

> So how is this that I can remove a dir, and all of it's files,
> owned by root, without permission, but I can't modify the
> permissions on the files? I dont understand.

You shouldn't be able to do that.

> Is this a bug, or is it normal behaviour. If so, how can I chown
> files other than switching to root? Also, where is the logic in
> allowing a user to remove directories owned by root that are in a
> subdir owned by another user.
>
> Is this standard UNIX behaviour? If so, sorry for the

It isn't.

> disruption. The chmod manpage is horrible at explaining in plain
> english what all of the permission bits are, and how they work.
> My understanding is that root owned files and dirs, with no "w"
> priv assigned to other users are only removeable by root. It
> appears thought that the files inherit the permissions for "w"
> from the owner of the dir that they are in.
>
> Can someone point me to a very well written explanation of all
> UNIX/Linux file permissions, that isn't the chmod manpage or a
> HOWTO that comes with RedHat? I'd really like to fully
> understand all the permissions settings, sticky bit, etc... and
> differences on files and dirs with these perms. Also, SUID and
> SGID dirs, etc..


Not that I could promise clear and concise explanation, but let's try.

1. To create or delete links in directory foo you must have write *and*
execute permissions on foo.
2. You cannot create or delete links if foo is on a read-only filesystem
(surprise, surprise) or has Immutable attribute set.
3. You cannot delete links from the directory that has Append-only
attribute set. Moreover, you can't overwrite them (with rename()).
4. You cannot create or delete links *to* Append-only or Immutable
objects.
5. You cannot remove a mountpoint or root.
6. To delete a link from sticky directory you should either
a) be owner of directory or
b) be owner of object the link points to or
c) have CAP_FOWNER capability.

7. There are two policies wrt to group of new objects: one is to use the
EGID of creating process and another - GID of the directory containing
the first link. If directory is not SGID we always follow the first
policy (EGID of creating process). If mount options permit *and* directory
is SGID we use the second one (inherit GID from the parent directory). In
that case subdirectories are marked with SGID too. (It's old BSD vs
Missed'em'Five story).

That's all about the effect of permissions on directory operations. Oh,
yeah - to read the contents of directory you need read permissions, to
use links in it you need execute permissions (read without execute -> see
them but can't reach them, execute without read -> blind but able to
move).


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.058 / U:0.624 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site