Names vs. Inodes

crispinat_private

David Wheeler wrote:

> Greg KH wrote:
> > Since the fd is only needed for audit, can we agree that this change
> > will be postponed until "stage 2"?
>
> Casey Schaufler replied:
> >Sure, we could, but I'd like to see a good reason not to
> >make it before it gets tossed.
>
> I don't see any critical reason for _not_ passing the fd, and I think
> a reasonable explanation's been made as to why the fd is needed
> (e.g., you CAN'T get it from the other structures, given dup(2)).
> There are lots of hooks and data values that someone _doesn't_ use, but
> if we know someone actually needs it _now_, let's put it in now. It'll
> make it easier for everyone to transition to "stage 2".

We have a basically similar situation with the "names vs. Inodes" issue
that arose several weeks ago at the USENIX BOF.  Several LSM projects use
inode-based access control, while some others used path name based access
control.

In SubDomain, we need to know the absolute path name of a file that a
process is trying to open.  LSM used to have a hook in namei that let us
construct this name.  More recent versions have removed this hook in favor
of a hook at the inode level.  Several people claim that it is
easy/possible to reconstruct the path name from the inode.  We've been
struggling for some weeks to make this practical, with little success.

If we can't build a practical means to reconstruct the path name from the
inode, we may want to put the name hook back in again.  We feel that it is
reasonable for an access control module to want to know the name of a file
being opened, and LSM should provide *some* way of determining that name.

If someone has a practical, detailed way to construct the name, please
speak up.  Note that it is not sufficient to be able to construct *some*
name that *could* have been used to open the file: we need the actual name
that was used to make the request.

On the other hand, if what you have is a heart-felt conviction that there
must be some way to do it ... save it, we've heard that :-)  We need the
details, not the encouragement.

Crispin

--
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc. http://wirex.com
Security Hardened Linux Distribution:       http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module