On Sat, Aug 27, 2022 at 07:14:30PM +0800, xiujianfeng wrote:
Hi,
在 2022/8/23 3:26, Günther Noack 写道:
On Mon, Aug 22, 2022 at 07:46:59PM +0800, Xiu Jianfeng wrote:
+TEST_F_FORK(layout1, unhandled_chmod) +{
- const struct rule rules[] = {
{
.path = file2_s3d1,
.access = LANDLOCK_ACCESS_FS_READ_FILE |
LANDLOCK_ACCESS_FS_WRITE_FILE,
},
{
.path = file3_s3d1,
.access = LANDLOCK_ACCESS_FS_READ_FILE |
LANDLOCK_ACCESS_FS_WRITE_FILE,
},
{},
- };
- const int ruleset_fd =
create_ruleset(_metadata, ACCESS_RW, rules);
- ASSERT_LE(0, ruleset_fd);
- enforce_ruleset(_metadata, ruleset_fd);
- ASSERT_EQ(0, close(ruleset_fd));
- ASSERT_EQ(0, test_chmod(file2_s3d1));
- ASSERT_EQ(0, test_fchmod(file2_s3d1));
- ASSERT_EQ(0, test_chmod(file3_s3d1));
- ASSERT_EQ(0, test_chmod(dir_s3d1));
+}
I missed it in the previous mail:
There are also the chown variants lchown() and fchownat(), as well as the chmod variant fchmodat(), which might be interesting to test, especially the symlink scenarios.
fchmodat() has a AT_SYMLINK_NOFOLLOW flag which does the chmod equivalent to lchown().
man fchmodat shows as follows: ... AT_SYMLINK_NOFOLLOW If pathname is a symbolic link, do not dereference it: instead operate on the link itself. This flag is not currently implemented. ...
so I suppose this can not be test. Please correct me if I am wrong.
Good point - I didn't realize that AT_SYMLINK_NOFOLLOW was not implemented for fchmodat. In that case, this only applies to lchown.
—Günther
--