On 2010-09-02, at 09:02, Serge E. Hallyn wrote:
> Quoting Andreas Dilger (adilger@xxxxxxxxx):
>> On 2010-08-19, at 23:31, Andrew G. Morgan wrote:
>>> Lots of small writes to 'any' file also tends to bang on this code.
>>> I've been wondering if it might make sense to cache, in the inode,
>>> that a file does *not* have any capabilities associated with it. That
>>> way the kernel wouldn't need to look up the xattrs twice for the same
>>> incapable file - which is, by far, the common case.
>>
>> That would be a blessing. I see a steady stream of
>> getxattr("security.capability") requests, and being able to disable this
>
> Do you think it would help at all to add a S_NO_POSIXCAPS
> to i_flags, and set that the first time we find that
> getxattr("security.capability") finds no capabilities?
> I.e. are these requests frequently for the same inode, or
> always for new ones?
That would be useful, or as you suggest a MNT_* flag.
>> (possibly even in the superblock with a flag) would avoid expensive RPCs on a
>> network filesystem.
>
> Hmm, as it is, the get_vfs_caps_from_disk() does not get called
> if MNT_NOSUID. But the cap_inode_need_killpriv() does, so a
> quick way to reduce that # for you would be to pass the inode
> to security_inode_need_killpriv (so it can get to mnt), and
> have that check for MNT_NOSUID, and then you can mount your
> network fs's with MNT_NOSUID... Would that help you?
Except there are users that do use SUID binaries on network filesystems (e.g. root or /usr filesystems). Something more like MNT_NOCAPXATTR would be better.
Cheers, Andreas
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
