Re: Filesystem Capabilities in 2.6?

[Bill Davidsen]

On Sat, 2 Nov 2002, Linus Torvalds wrote:

> There are two fairly trivial ways to do it:
> 
>  - put the actual data in the directory entry itself. This is efficient, 
>    but not very easily extensible, since most directory structures have 
>    serious size limitations.

I think the arguments against having different capabilities for the same
executable by different names have been made. It does seem that this would
mean a symbolic link to the enabled directory entry would work and have
capabilities, while a hard link to the inode would not?

Being hard to understand is one source of security errors of the "I didn't
mean to do that" type. 
 
>  - Make a new file type, and put just that information in the directory
>    (so that it shows up in d_type on a readdir()).  Put the real data in
>    the file, ie make it largely look like an "extended symlink".

I thought about symlink-like thngs when I was trying to envision an ACL by
group, allowing control of a group other than the non-owner group to have
more (or fewer) rights.
 
> The latter approach is probably a bit too reminiscent of a Windows
> "shortcut" aka LNK file to some people, but hey, maybe it's a good idea.

The problem with any form of link by name is that there's no easy way to
tell from the inode how many pointers there are, and from the link to tell
when the link target has changed. I could envision security attacks based
on changing the base file and having capabilities apply via the link.

None of this is beyond implementation, but the idea of having something on
a file inode certainly removes all attacks taking advantage of the link
relationship. The best way to make something secure is to eliminate the
need for it.

-- 
bill davidsen <[e-mail]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.