From: Sharyathi Nagesh <sharyath@in.ibm.com>
To: Wei Yongjun <yjwei@cn.fujitsu.com>, ltp-list@lists.sourceforge.net
Cc: mbeeraka@in.ibm.com
Subject: Re: [LTP] Issue observed with chmod05, fchmod05 test cases
Date: Mon, 20 Jul 2009 16:55:16 +0530 [thread overview]
Message-ID: <4A64541C.9090408@in.ibm.com> (raw)
In-Reply-To: <4A486E66.5050102@cn.fujitsu.com>
[-- Attachment #1: Type: text/plain, Size: 1735 bytes --]
Hi
I was able to understand the problem...
This is what I learnt
Supplementary group IDs of a process is inherited from its parent process, so
who ever spawns the process transfer its supplementary group ids also to its
child process.
in our test case scenario checking the supplementary group IDs of root which is
spawning the test cases fchmod5 and chmod5 shows this
---------------------------------------------------------
cat test.c
---------------------------------------------------------
int main()
{
int size = 10;
int i, index;
gid_t list[10];
index = getgroups(size, list);
for ( i =0 ;i < index; i++)
printf("\n list[%d]:%d", i, list[i]);
printf("\n");
}
---------------------------------------------------------
[root@mx3350a sharyathi]# ./a.out
list[0]:0
list[1]:1
list[2]:2
list[3]:3
list[4]:4
list[5]:6
list[6]:10
---------------------------------------------------------
This shows that bin->GID (1) is one of the supplementary group IDs of the process
while nobody->GID (99) is not.
So in the kernel code
--------------------------------------------------------
if (ia_valid & ATTR_MODE) {
umode_t mode = attr->ia_mode;
if (!in_group_p(inode->i_gid) && !capable(CAP_FSETID))
mode &= ~S_ISGID;
inode->i_mode = mode;
}
--------------------------------------------------------
S_ISGID is cleared in case file attribute is nobody and not in case of GID
being bin
I was thinking of what could be the best solution as earlier solution proposed
are not fool proof
Attaching a fix I though is the best way to handle the issue
Thanks
Yeehaw
[-- Attachment #2: fix_supplementary_group_id_issue.patch --]
[-- Type: text/x-patch, Size: 1468 bytes --]
Index: ltp-full-20090430/testcases/kernel/syscalls/chmod/chmod05.c
===================================================================
--- ltp-full-20090430.orig/testcases/kernel/syscalls/chmod/chmod05.c 2009-04-25 23:22:44.000000000 +0530
+++ ltp-full-20090430/testcases/kernel/syscalls/chmod/chmod05.c 2009-07-20 16:34:07.000000000 +0530
@@ -240,6 +240,10 @@
tst_brkm(TBROK, cleanup, "mkdir(2) of %s failed: %s", TESTDIR,
strerror(errno));
}
+
+ if(setgroups(1, &nobody_u->pw_gid) == -1)
+ tst_brkm(TBROK, cleanup, "Couldn't change supplementary group Id: %s",
+ strerror(errno));
if (chown(TESTDIR, nobody_u->pw_uid, bin_group->gr_gid) == -1)
tst_brkm(TBROK, cleanup, "Couldn't change owner of testdir: %s",
Index: ltp-full-20090430/testcases/kernel/syscalls/fchmod/fchmod05.c
===================================================================
--- ltp-full-20090430.orig/testcases/kernel/syscalls/fchmod/fchmod05.c 2009-07-20 16:22:56.000000000 +0530
+++ ltp-full-20090430/testcases/kernel/syscalls/fchmod/fchmod05.c 2009-07-20 16:32:26.000000000 +0530
@@ -218,6 +218,10 @@
tst_brkm(TBROK, cleanup, "mkdir(2) of %s failed", TESTDIR);
}
+ if(setgroups(1, &nobody_u->pw_gid) == -1)
+ tst_brkm(TBROK, cleanup, "Couldn't change supplementary group Id: %s",
+ strerror(errno));
+
if (chown(TESTDIR, nobody_u->pw_uid, bin_group->gr_gid) == -1)
tst_brkm(TBROK, cleanup, "Couldn't change owner of testdir: %s",
strerror(errno));
[-- Attachment #3: Type: text/plain, Size: 389 bytes --]
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
[-- Attachment #4: Type: text/plain, Size: 155 bytes --]
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
next prev parent reply other threads:[~2009-07-20 11:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-29 7:00 [LTP] Issue observed with chmod05, fchmod05 test cases Sharyathi Nagesh
2009-06-29 7:33 ` Wei Yongjun
2009-06-29 10:30 ` Sharyathi Nagesh
2009-07-02 4:34 ` Sharyathi Nagesh
2009-07-20 11:25 ` Sharyathi Nagesh [this message]
2009-07-20 15:56 ` Garrett Cooper
2009-07-21 8:57 ` Sharyathi Nagesh
2009-07-30 18:28 ` Subrata Modak
2009-07-31 1:38 ` Sharyathi Nagesh
2009-07-31 1:54 ` Subrata Modak
2009-08-06 11:39 ` [LTP] [PATCH][RESEND] " Sharyathi Nagesh
2009-08-07 12:41 ` Subrata Modak
2009-09-15 10:27 ` Sharyathi Nagesh
2009-09-16 15:16 ` Subrata Modak
-- strict thread matches above, loose matches on Subject: below --
2009-07-21 9:35 [LTP] " Munipradeep Beerakam
2009-07-21 11:31 ` Sharyathi Nagesh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A64541C.9090408@in.ibm.com \
--to=sharyath@in.ibm.com \
--cc=ltp-list@lists.sourceforge.net \
--cc=mbeeraka@in.ibm.com \
--cc=yjwei@cn.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox