Re: [PATCH v2] xfs: publish UUID in struct super_block

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 2, 2017 at 8:09 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
...
>>> > Non-uniqueue uuids are an absolute no-go.
>>>
>>> I'm not sure I follow your specific concern here.
>>> Surely you are not proposing to get rid of the nouuid
>>> mount option, are you? So what's the point of hiding
>>> the fact that there are 2 mounted filesystems with the
>>> same uuid from VFS?
>>
>> Because it breaks people using s_uuid.
...

>>
>> It's not.  The whole point of exporting s_uuid is to have a uniqueue
>> identifier for a superblock.  If it's not actually uniqueue there is
>> no point in having or using it.
>
> Well it's useful for my use case. I need s_uuid as a sanity check
> and IIUC, so does cleancache.
> I don't know about EVM/IMA, but apparently, it did well
> with pseudo uniqueness so far.
>

Mimi,

Can you please comment on the implication of starting to publish
sb->s_uuid by xfs on EVM/IMA.

Are there any persistent integrity signatures that could be broken,
because an xfs filesystem once published zeroes for sb->s_uuid
and will start to publish non-zero sb->s_uuid?

BTW, the same question applies w.r.t ubifs, which are also going to
start publishing sb->s_uuid, although I don't if there are ubifs+evm users.

Thanks,
Amir.



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux