On Tuesday 05 November 2002 05:47 pm, Bill Davidsen wrote:
> 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.
Not to mention what happens if a file gets lost - fsck puts it in the
lost+found directory, but without the protection specified by the owner.
> > - 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.
absolutely
-- ------------------------------------------------------------------------- Jesse I Pollard, II Email: pollard@navo.hpc.milAny opinions expressed are solely my own. - 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/
This archive was generated by hypermail 2b29 : Thu Nov 07 2002 - 22:00:43 EST