Re: [SLUG] confused about file permissions

From: Eben King (eben1@tampabay.rr.com)
Date: Sat Oct 29 2005 - 19:49:11 EDT


On Sat, 29 Oct 2005, 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,

Deletion doesn't affect the file itself:

[eben@pc tmp]$ mkdir 1
[eben@pc tmp]$ mkdir 2
[eben@pc tmp]$ echo foo > 1/bar
[eben@pc tmp]$ echo foo > 1/bar
[eben@pc tmp]$ ln 1/bar 2
[eben@pc tmp]$ ls -li 1 2
1:
total 4.0K
 112343 4.0K -rw-rw-r-- 2 eben eben 4 Oct 29 19:17 bar

2:
total 4.0K
 112343 4.0K -rw-rw-r-- 2 eben eben 4 Oct 29 19:17 bar
[eben@pc tmp]$ rm 1/bar
[eben@pc tmp]$ ls -li 1 2
1:
total 0

2:
total 4.0K
 112343 4.0K -rw-rw-r-- 1 eben eben 4 Oct 29 19:17 bar
[eben@pc tmp]$ ls -ldi 1 2
 112341 4.0K drwxrwxr-x 2 eben eben 4.0K Oct 29 19:18 1/
 112342 4.0K drwxrwxr-x 2 eben eben 4.0K Oct 29 19:17 2/
# ^-- inode link count --^
[eben@pc tmp]$ cat 2/bar
foo
[eben@pc tmp]$

> 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.

They would, but they don't matter. "Deletion" is just removal of the file's
entry from the directory (so it's the *directory's* permissions that matter,
since it's the one you're modifying), and decrementing its link count
(wherever that's stored). I can delete a root-owned file, even though I'm
not root.

[eben@pc tmp]$ ls -l 1
total 4.0K
4.0K -rw-r--r-- 1 root root 4 Oct 29 19:36 bar
[eben@pc tmp]$ ls -ld 1
4.0K drwxrwxr-x 2 eben eben 4.0K Oct 29 19:36 1/
[eben@pc tmp]$ id
uid=500(eben) gid=500(eben)
groups=500(eben),6(disk),7(lp),502(dos),504(graphics),506(modem),1006(sndadm)
[eben@pc tmp]$ rm 1/bar
rm: remove write-protected regular file `1/bar'? y
[eben@pc tmp]$ ls -l 1
total 0

Nothing's special about the "original":

[eben@pc tmp]$ ln 2/bar 2/foo
[eben@pc tmp]$ ls -li 2
total 8.0K
 112343 4.0K -rw-rw-r-- 2 eben eben 4 Oct 29 19:17 bar
 112343 4.0K -rw-rw-r-- 2 eben eben 4 Oct 29 19:17 foo
[eben@pc tmp]$ rm 2/bar
[eben@pc tmp]$ ls -li 2
total 4.0K
 112343 4.0K -rw-rw-r-- 1 eben eben 4 Oct 29 19:17 foo

As you here, I made a link from 2/bar (which as you recall was itself a link
to something else), and deleted 2/bar, and the inode remained the same.
All links had the same inode throughout.

> I would have assumed that the logic would be:
>
> if (permissions in directory allows deletion by user x)
> if (permissions on file allow deletion by user x)
> operation allowed;
> else
> operation not allowed;
> else
> operation not allowed;
>
> 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)?
>
> So if the above isn't the logic, what is?

Something like

if (permissions in directory allows deletion by user x)
  remove file entry from dir
  decrement link count
else
  error
fi

-- 
-eben    ebQenW1@EtaRmpTabYayU.rIr.OcoPm    home.tampabay.rr.com/hactar

Hanlon's Razor: "Never attribute to malice that which can be adequately explained by stupidity." Derived from Robert Heinlein

----------------------------------------------------------------------- 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:29 EDT