于 2013年12月15日 19:26, Jean-Pierre André 写道:
> Hi,
>
> It still was buggy, please try the one attached....
>
> Regards
>
> Jean-Pierre
>
>
Hi, I just wanted to send email to you. I just saw the code, I think the
line-159 and line-171 in tests/chown/00.t will run failed in linux:xfs.
157 expect 0 -u 65534 -g 65533,65532 chown ${n0} 65534 65532
158 case "${os}:${fs}" in
159 Linux:*)
160 expect 06555,65534,65532 lstat ${n0} mode,uid,gid
161 ;;
162 *)
163 expect 0555,65534,65532 lstat ${n0} mode,uid,gid
164 ;;
165 esac
166 expect 0 chmod ${n0} 06555
167 expect 06555 lstat ${n0} mode
168 expect 0 -u 65534 -g 65533,65532 -- chown ${n0} -1 65533
169 case "${os}:${fs}" in
170 Linux:*)
171 expect 06555,65534,65533 lstat ${n0} mode,uid,gid
172 ;;
173 *)
174 expect 0555,65534,65533 lstat ${n0} mode,uid,gid
175 ;;
176 esac
The Ext fs will not clear the SUID and SGID bits after chown a directory.
The VFS only requests clearing it if it's not a directory, in chown_common()
upstream:
if (!S_ISDIR(inode->i_mode))
newattrs.ia_valid |=
ATTR_KILL_SUID | ATTR_KILL_SGID | ATTR_KILL_PRIV;
But xfs always clear it by himself:
in xfs_setattr_nonsize() upstream:
/*
* Change file ownership. Must be the owner or privileged.
*/
if (mask & (ATTR_UID|ATTR_GID)) {
/*
* CAP_FSETID overrides the following restrictions:
*
* The set-user-ID and set-group-ID bits of a file will be
* cleared upon successful return from chown()
*/
if ((ip->i_d.di_mode & (S_ISUID|S_ISGID)) &&
!capable(CAP_FSETID))
ip->i_d.di_mode &= ~(S_ISUID|S_ISGID);
So you should not just use Linux:* to judge it.
Actually glusterfs not clear it now, but I reported it as a bug to
glusterfs developers, because one glusterfs developer said glusterfs
should as same as xfs, when I use xfs backend to be the glusterfs server.
So after the glusterfs developers checked the bug, they will give a
assured answer.
Others I test passed for glusterfs and xfs.
Wait for your new modification:)
Thank you,
Zorro Lang
> Jean-Pierre André wrote:
>> Hi again,
>>
>> Hopefully, the attached file is the correct one.
>>
>> Sorry for the confusion.
>>
>> Regards
>>
>> Jean-Pierre
>>
>>
>> Jean-Pierre André wrote:
>>> Hi,
>>>
>>> Today, I have made the change I was suggesting, and
>>> tested again all the file systems I could gather :
>>>
>>> On Linux : ext3, ext4, xfs, btrfs, ntfs-3g
>>> on OpenIndiana (SunOS) : ZFS, UFS, ntfs-3g
>>>
>>> All of them pass with no error. I just discovered two
>>> unexpected (but correct) behaviors in link/00.t on
>>> UFS (fixed now).
>>>
>>> The changed files are attached, can you make a
>>> new try on glusterfs, just to be sure I have forgotten
>>> nothing ?
>>>
>>> See also my comments below.
>>>
>>> Thanks again for your collaboration.
>>>
>>> Regards
>>>
>>> Jean-Pierre
>>>
>>> Zorro Lang wrote:
>>>> 于 2013年12月14日 01:51, Jean-Pierre André 写道:
>>>>> Hi,
>>>>>
>>>>> Zorro Lang wrote:
>>>>>> 于 2013年12月13日 16:17, Jean-Pierre André 写道:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Thanks for the proposed patches.
>>>>>>>
>>>>>>> What are the situations where glusterfs should not behave
>>>>>>> like ext3/ext4 on Linux ?
>>>>>> The posix is a standard, GNU/Linux follow this standard, so the
>>>>>> filesystem in linux should have same behavior. The glusterfs
>>>>>> nearly no difference with other fs, but there are still to things
>>>>>> I need to do:
>>>>>
>>>>> [...]
>>>>>
>>>>> Actually, what I meant, is that in all the situations where
>>>>> you made changes, glusterfs behaves the same as ext3
>>>>> and xfs on Linux.
>>>>>
>>>> Oh, I think I have explained all the situations where I made
>>>> changes on last email.
>>>>> And there are known cases where Solaris file systems or
>>>>> freebsd ones behave differently from Linux ones.
>>>>>
>>>>> So you end up enumerating all file systems, like below.
>>>>> This hides what is specific to an operating system and
>>>>> would require to add cases for ext4 or newer file
>>>>> systems.
>>>>>
>>>>>>>> case "${os}:${fs}" in
>>>>>>>> -Linux:ext3)
>>>>>>>> +Linux:ext3 | Linux:xfs | Linux:glusterfs)
>>>>>>>> test_check $ctime1 -lt $ctime2
>>>>>>>> ;;
>>>>>>>> -*)
>>>>>>>> +*:ext3 | *:xfs | *:ZFS | *:ntfs-3g | *:UFS)
>>>>>>>> test_check $ctime1 -eq $ctime2
>>>>>>>> + ;;
>>>>>>>> +*)
>>>>>>>> + test_check $ctime1 -le $ctime2
>>>>>>>> ;;
>>>>>>>> esac
>>>>>
>>>> The ctime changed by linux VFS, so all linux local filesystem must
>>>> update the ctime. But some fs with FUSE maybe update or not update
>>>> the ctime.
>>>
>>> Actually not, I have checked again. Fuse does not
>>> call the file system when uid == gid == -1, so the
>>> file system cannot update the ctime.
>>>
>>>> I haven't test UFS, ZFS and ntfs-3g in Linux, I just knew xfs,ext
>>>> and glusterfs will use "$ctime1 -lt $ctime2" in linux, and I have
>>>> made sure that by ask the ext, xfs and glusterfs developer.
>>>> The original code is:
>>>> "test_check $ctime1 -eq $ctime2 "
>>>> So I think all of the $os:$fs which the pjd-fstest supported(in
>>>> README) will not update the ctime previously. Now I just made sure
>>>> the ext, xfs, glusterfs in linux, so I just wrote
>>>> "+Linux:ext3 | Linux:xfs | Linux:glusterfs)
>>>> test_check $ctime1 -lt $ctime2 "
>>>> at first.
>>>> Then I want to keep other situations to use "-eq".
>>>> Last I use "-le" to delegate "need not" which posix said for others
>>>> "unclear" situations.
>>>
>>> Yes, your proposal is correct, but it can be simplified
>>> to make it easier to maintain.
>>>
>>>
>>>>
>>>>> So I would suggest writing the above like
>>>>>
>>>>> case "${os}:${fs}" in
>>>>> Linux:glusterfs)
>>>>> # test for glusterfs if it is different from most Linux ones,
>>>>> ;;
>>>> the linux:glusterfs not need to be wrote specifically, it's same
>>>> with ext3 and xfs in linux. If others fs different from most linux
>>>> ones, it can be wrote here.
>>>
>>> Yes of course. What I wrote above was a generic
>>> pattern to be adapted to each specific case.
>>>
>>>>> Linux:*)
>>>>> # usual test for Linux ones (ext3, ext4, and usually glusterfs)
>>>>> ;;
>>>>> # specific tests here for other OS when needed
>>>>> *)
>>>>> # tests not applicable to Linux
>>>>> ;;
>>>>> esac
>>>>>
>>>>
>>>>> Advantages :
>>>>> - glusterfs would probably not be a special case
>>>>> - special situations for some OS or fs are taken into
>>>>> account
>>>>> - no update is needed for newer file systems (e.g. ext4)
>>>> when I tested ext4 I often use fs=ext3, and test passed :)
>>>
>>> I confirm this. Same for btrfs.
>>>
>>>>> - file systems, like ntfs-3g, whose behavior depends
>>>>> on the OS are easily taken into account
>>>>> - changes in behavior of a file system can be detected
>>>>> (and your tests showed a change in ext3 behavior
>>>>> which may have to be propagated to other file systems)
>>>> I think maybe we should test all "unclear" situations in all the
>>>> $os:$fs which the pjd-fstest support(in README or tests/conf), to
>>>> make sure the current status of every $os:$fs, before public the
>>>> newest code.
>>>
>>> I think I have tested all these cases, and found another
>>> unclear one : when a hard link is unsuccessful, UFS does
>>> not update the ctime, but all other file systems do, and
>>> Posix does not mention ctime on unsuccessful completion.
>>>
>>>>>
>>>>> I cannot do this change now, I will make a proposal
>>>>> later.
>>>> OK, I have given you my thinking here, I think you can decide how
>>>> to do the final modification:) If need me to do something I will
>>>> try my best:)
>>>>
>>>> Thank you,
>>>> Zorro Lang
>>>>>
>>>>> Regards
>>>>>
>>>>> Jean-Pierre
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
ntfs-3g-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
