Messages in this thread | | | Subject | Re: [PATCH] mm/shmem.c: don't set 'seals' to 'F_SEAL_SEAL' in shmem_get_inode | From | "yukuai (C)" <> | Date | Wed, 27 Nov 2019 14:46:55 +0800 |
| |
On 2019/11/27 12:24, Hugh Dickins Wrote: > On Wed, 27 Nov 2019, yu kuai wrote: > >> 'seals' is set to 'F_SEAL_SEAL' in shmem_get_inode, which means "prevent >> further seals from being set", thus sealing API will be useless and many >> code in shmem.c will never be reached. For example: > > The sealing API is not useless, and that code can be reached. > >> >> shmem_setattr >> if ((newsize < oldsize && (info->seals & F_SEAL_SHRINK)) || >> (newsize > oldsize && (info->seals & F_SEAL_GROW))) >> return -EPERM; >> >> So, initialize 'seals' to zero is more reasonable. >> >> Signed-off-by: yu kuai <yukuai3@huawei.com> > > NAK. > > See memfd_create in mm/memfd.c (code which originated in mm/shmem.c, > then was extended to support hugetlbfs also): sealing is for memfds, > not for tmpfs or hugetlbfs files or SHM. Without thinking about it too > hard, I believe that to allow sealing on tmpfs files would introduce > surprising new behaviors on them, which might well raise security issues; > and also be incompatible with the guarantees intended by sealing.
Thank you for your response. Yu Kuai
| |