Messages in this thread | | | Date | Mon, 20 Mar 2000 16:27:14 +0100 | From | Jamie Lokier <> | Subject | Re: Open by inode (was Re: your mail) |
| |
Donald Becker wrote: > >The fact that there's no standardised API for open-by-inode isn't > >necessarily a feature. And anyway, even if Jamie's feature got > >integrated, I'm sure it would be off by default. > > We have implemented open-by-inode-number as a kernel module for 2.2.*. > It approximately follows the "[major:minor:inode]" syntax in the /proc > psuedo-filesystem. I encourage anyone else implementing a similar > mechanism to follow the same syntax. > ... > > Most filesystems get *really nervous* when you access an inconsistent inode, > and some even become unhappy if you merely reference a inode with a zero > count. We only use it with devices that are marked unwritable, preferably > with a hardware mechanism or loopback mounted. > > Needless to say, any mechanism that so readily cause kernel corruption is > available only to 'root', so the file security issue never even needs to be > considered.
My patch is for ext2 only. It adds a new ext2 attribute meaning "this is an open-by-inode directory". So you create .inode in a filesystem, chattr it, and then .inode/<number> refers to a specific inode in that filesystem.
Being ext2-specific, the patch ensures the correct behaviour when you try opening a non-existent inode: the entry in .inode doesn't exist. A little care is needed to avoid negative dentries here.
Because this works, it is safe to use on writable filesystems. Access through .inode is determined by the permissions on that directory as usual, and of course access to the files and directories themselves is determined by their permission as usual too.
It seems to work very well, but I don't have a use for it so I've never given it a thorough test.
My patch is better than Donald Becker's for another reason: you can use it over NFS ;-)
enjoy, -- Jamie
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |