lkml.org 
[lkml]   [2002]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Filesystem Capabilities in 2.6?
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 <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

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

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