On 2017/8/16 19:10, Amir Goldstein Wrote:
> On Wed, Aug 16, 2017 at 12:19 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>> On Tue, Aug 15, 2017 at 6:16 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>>> On Tue, Aug 15, 2017 at 5:56 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote:
>>
>>>> IIUC, so now "chattr -p <id>" will fail on overlayfs (assume file has not
>>>> been copied up yet).
>>>>
>>>
>>> Yap.
>>>
>>>> IOW, on overlayfs, will it be responsibility of user space to make
>>>> sure file has been copied up, for chattr operation to succeed? Does that
>>>> mean we need to modify chattr to open file for WRITE instead of READ.
>>>>
>>>
>>> I guess that would make sense.
>>> I only wonder what was the reason for chattr to open RDONLY in
>>> the first place (cc Ted)??
>>
>> What about copy up of flags? Should we?
>
> IMO we should start with copying KSTAT_ATTR_FS_IOC_FLAGS,
> which can already be available in kstat.
> Other "standard" FS_IOC_FLAGS can be copied up when statx
> gets support for those flags.
>
> FYI, chattr [+/-]<flags> does:
> - fgetflags(&flags): {open OPEN_FLAGS; ioctl EXT2_IOC_GETFLAGS}
> - change flags
> - fsetflags(&flags): {open OPEN_FLAGS; ioctl EXT2_IOC_SETFLAGS}
>
> OPEN_FLAGS is defined independently in lib/e2p/f{get,set}flags.c as
> (O_RDONLY|O_NONBLOCK|O_LARGEFILE), so technically all it
> takes is to change the defined in lib/e2p/fsetflags.c to O_RDWR
> and then chattr [+/-]<flags> can be used for preemptive "copy up flags"
> by userspace (*) to work around issues which require flags copy up.
>
Hi Amir:
I notice that RDONLY is required if file is immutable or append-only,
chattr will fail with EPERM return value if we use O_RDWR open flag to open
a immutable or append-only file. So I think we cannot simply change
to O_RDWR in lib/e2p/fsetflags.c, we should take care about this special,
please see check in may_open() and __inode_permission().
Thanks,
Zhangyi.
--
To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
