[LTP] Issue observed with chmod05, fchmod05 test cases

[LTP] Issue observed with chmod05, fchmod05 test cases

[Sharyathi Nagesh]

Hi
   I am observing this anomaly with these 2 test cases chmod05.c and fchmod05.c.
These 2 test cases are written to test the POSIX standard which says:

  	"If the calling process is not privileged  (Linux:  does  not  have  the
        CAP_FSETID  capability),  and  the group of the file does not match the
        effective group ID of the process or one  of  its  supplementary  group
        IDs,  the  S_ISGID  bit  will be turned off, but this will not cause an
        error to be returned."


So the test case will try to setup a file in which the GID of the test/tmp file will be 
different from the effective group ID of the running process. But this criterion is found to 
be not sufficient condition for the clearing the S_ISGID bit of the file

------------------------------------------------------------
Ex:
There are 2 users nobody (uid=99, gid=99) and bin (uid=1, gid=1)
let as assume temporary file as /tmp/zxcv

Test will Pass if
     Set UID/GID of /tmp/zxcv to            nobody->uid & nobody->GID
     Set eUID/eGID of process to           nobody->uid & bin->GID

Test will Fail if
     Set UID/GID of /tmp/zxcv to            nobody->uid & bin->GID
     Set eUID/eGID of process to           nobody->uid & nobody->GID

I verified supplementary group IDs for both 'nobody' and 'bin' and they are mutually 
exclusive and none of the other is supplementary group ID of the ID being tested
------------------------------------------------------------

Should we treat this as Test case issue or kernel bug?

Thanks
Yeehaw

------------------------------------------------------------------------------
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] Issue observed with chmod05, fchmod05 test cases

[Wei Yongjun]

Sharyathi Nagesh wrote:
> Hi
>   I am observing this anomaly with these 2 test cases chmod05.c and
> fchmod05.c.
> These 2 test cases are written to test the POSIX standard which says:
>
>      "If the calling process is not privileged  (Linux:  does  not 
> have  the
>        CAP_FSETID  capability),  and  the group of the file does not
> match the
>        effective group ID of the process or one  of  its 
> supplementary  group
>        IDs,  the  S_ISGID  bit  will be turned off, but this will not
> cause an
>        error to be returned."
>
>
> So the test case will try to setup a file in which the GID of the
> test/tmp file will be different from the effective group ID of the
> running process. But this criterion is found to be not sufficient
> condition for the clearing the S_ISGID bit of the file
>
> ------------------------------------------------------------
> Ex:
> There are 2 users nobody (uid=99, gid=99) and bin (uid=1, gid=1)
> let as assume temporary file as /tmp/zxcv
>
> Test will Pass if
>     Set UID/GID of /tmp/zxcv to            nobody->uid & nobody->GID
>     Set eUID/eGID of process to           nobody->uid & bin->GID
>
> Test will Fail if
>     Set UID/GID of /tmp/zxcv to            nobody->uid & bin->GID
>     Set eUID/eGID of process to           nobody->uid & nobody->GID
>
> I verified supplementary group IDs for both 'nobody' and 'bin' and
> they are mutually exclusive and none of the other is supplementary
> group ID of the ID being tested
> ------------------------------------------------------------
>
> Should we treat this as Test case issue or kernel bug?

The different of 'nobody' and 'bin' is bin->GID has the CAP_FSETID 
capability, but nobody->GID has not, I think.

Regards.





------------------------------------------------------------------------------
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] Issue observed with chmod05, fchmod05 test cases

[Sharyathi Nagesh]

Wei Yongjun
>>
>> Should we treat this as Test case issue or kernel bug?
> 
> The different of 'nobody' and 'bin' is bin->GID has the CAP_FSETID 
> capability, but nobody->GID has not, I think.
> 
I am facing some issues with getcap, how else can I verify the USER capabilities
If there is a simpler way to check user capabilities please let me know

My efforts to use getcap fails

getcap /tmp/test1
Failed to get capabilities for file `/tmp/test1'
  (Function not implemented)

Thank you

------------------------------------------------------------------------------
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] Issue observed with chmod05, fchmod05 test cases

[Sharyathi Nagesh]

Wei Yongjun wrote:

>> ------------------------------------------------------------
>>
>> Should we treat this as Test case issue or kernel bug?
> 
> The different of 'nobody' and 'bin' is bin->GID has the CAP_FSETID 
> capability, but nobody->GID has not, I think.


I tried with a small program to check out the capabilities of bin and nobody couldn't find 
any difference

This is what I tried
Program I used
------------------------------
int main()
{
	cap_t cap = cap_get_proc();
	printf("Running with uid %d\n", getuid());
	printf("Running with capabilities: %s\n", cap_to_text(cap, NULL));
	cap_free(cap);
	return 0;
}
------------------------------
Running the program under different user gave same information

mx3455a:/home/sharyathi # su bin
bin@mx3455a:/home/sharyathi> ./a.out
Running with uid 1
Running with capabilities: =
bin@mx3455a:/home/sharyathi> exit

mx3455a:/home/sharyathi # su nobody
nobody@mx3455a:/home/sharyathi> ./a.out
Running with uid 65534
Running with capabilities: =

Thanks
Sharyathi N

------------------------------------------------------------------------------
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] Issue observed with chmod05, fchmod05 test cases

[Sharyathi Nagesh]

[-- 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

Re: [LTP] Issue observed with chmod05, fchmod05 test cases

[Garrett Cooper]

On Mon, Jul 20, 2009 at 4:25 AM, Sharyathi Nagesh<sharyath@in.ibm.com> wrote:
> 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

Hi Yeehaw,
    1. You didn't provide sign-off, as noted in the DCO:
http://ltp.sourceforge.net/DCO.txt
    2. This appears to be a legitimate documentation bug (at least as
far as the manpages for 2.6.29-r5 are concerned), because I can't find
a single reference to nobody in the manpage, as far as special
importance is concerned. Furthermore, looking at the OpenGroup's
documentation, I don't see anything there either:
http://www.opengroup.org/onlinepubs/000095399/functions/getgroups.html
. So, I'm a bit stumped as to whether or not we'd be doing the right
thing by `fixing' this test.
Thanks,
-Garrett

------------------------------------------------------------------------------
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
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] Issue observed with chmod05, fchmod05 test cases

[Sharyathi Nagesh]

Garret

> 
> Hi Yeehaw,
>     1. You didn't provide sign-off, as noted in the DCO:
> http://ltp.sourceforge.net/DCO.txt
Excuse me for missing that out, if this patch format is okie I will resend it with the 
sign-off included in it
>     2. This appears to be a legitimate documentation bug (at least as
> far as the manpages for 2.6.29-r5 are concerned), because I can't find
> a single reference to nobody in the manpage, as far as special
> importance is concerned. Furthermore, looking at the OpenGroup's
> documentation, I don't see anything there either:
> http://www.opengroup.org/onlinepubs/000095399/functions/getgroups.html

  I am not very clear with what you are pointing at, but let me take a shot. bin and nobody 
are 2 users used in the test case. I am not sure who or where it is getting created, but 
what I did observe is that they don't have the same privileges. GID of bin is in the list of 
supplementary group ids of root while nobody is not. If this is the case chmod/fchmod won't 
clear S_IGSID bit of the file, as you can read from man page of chmod/fchmod.
  Nobody won't be in any man page as this User was created by LTP, I suppose, to use in this 
test case.
Thanks
Sharyathi N


------------------------------------------------------------------------------
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
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] Issue observed with chmod05, fchmod05 test cases

[Munipradeep Beerakam]

[-- Attachment #1: Type: text/plain, Size: 217 bytes --]

Hi Sharyathi,

This is the forwarded mail containing the patch for chmod05 in new LTP
provided by Wei Yongjun <yjwei@cn.fujitsu.com>.
Is this the functionality you are also looking for and trying to fix?

Thanks
Muni

[-- Attachment #2: Forwarded message - [LTP] [PATCH 1/2] chmod05: fix to modify the group ownership before do dir chmod --]
[-- Type: message/rfc822, Size: 7684 bytes --]

From: Wei Yongjun <yjwei@cn.fujitsu.com>
To: Subrata Modak <subrata@linux.vnet.ibm.com>, ltp-list@lists.sourceforge.net
Subject: [LTP] [PATCH 1/2] chmod05: fix to modify the group ownership before do dir chmod
Date: Mon, 08 Jun 2009 14:13:15 +0800
Message-ID: <4A2CABFB.3010207@cn.fujitsu.com>

Refer to the manpage:

  # man 2 chmod
  If the calling process is not privileged (Linux: does not have the
  CAP_FSETID capability), and the group of the file does not match
  the effective group ID of the process or one of its supplementary
  group IDs, the S_ISGID bit will be turned off, but this will not
  cause an error to be returned.

So, if we want S_ISGID bit be turned off after chmod(), we can not have
the CAP_FSETID capability and not match the effective group ID. The 'bin'
group always has the CAP_FSETID capability, so we can not change the own
of the TESTDIR to 'bin' group, instead, 'nobody' can be used.

This patch fixed the problem by change gid of chown to 'nobody' group and
change the gid of setegid() to 'bin' group.

Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
---
 testcases/kernel/syscalls/chmod/chmod05.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/testcases/kernel/syscalls/chmod/chmod05.c b/testcases/kernel/syscalls/chmod/chmod05.c
index 4504aaa..c6f1225 100644
--- a/testcases/kernel/syscalls/chmod/chmod05.c
+++ b/testcases/kernel/syscalls/chmod/chmod05.c
@@ -177,7 +177,7 @@ int main(int ac, char **av)
 			if ((PERMS & ~S_ISGID) != dir_mode) {
 				tst_resm(TFAIL, "%s: Incorrect modes 0%03o, "
 					 "Expected 0%03o", TESTDIR, dir_mode,
-					 PERMS);
+					 PERMS & ~S_ISGID);
 			} else {
 				tst_resm(TPASS,
 					 "Functionality of chmod(%s, %#o) successful",
@@ -241,12 +241,12 @@ void setup()
 				strerror(errno));
 	}

-	if (chown(TESTDIR, nobody_u->pw_uid, bin_group->gr_gid) == -1)
+	if (chown(TESTDIR, nobody_u->pw_uid, nobody_u->pw_gid) == -1)
 		tst_brkm(TBROK, cleanup, "Couldn't change owner of testdir: %s",
 				strerror(errno));

-	/* change to nobody:nobody */
-	if (setegid(nobody_u->pw_gid) == -1 ||
+	/* change to nobody:bin */
+	if (setegid(bin_group->gr_gid) == -1 ||
 		 seteuid(nobody_u->pw_uid) == -1)
 		tst_brkm(TBROK, cleanup, "Couldn't switch to nobody:nobody: %s",
 				strerror(errno));
-- 
1.6.0.2.530.g67faa





------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
looking to deploy the next generation of Solaris that includes the latest 
innovations from Sun and the OpenSource community. Download a copy and 
enjoy capabilities such as Networking, Storage and Virtualization. 
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

[-- 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

Re: [LTP] Issue observed with chmod05, fchmod05 test cases

[Sharyathi Nagesh]

Muni
  What I am trying to say is, this fix assumes that
Bin->GID is part of supplementary group IDs of root and nobody->GID is not.
There is no basis for this assumption. If nobody->GID is part of supplementary group ID than 
it will fail again.
  So instead specifically set the supplementary group ID of the process to avoid confusion
Thanks
Yeehaw
> 
> diff --git a/testcases/kernel/syscalls/chmod/chmod05.c b/testcases/kernel/syscalls/chmod/chmod05.c
> index 4504aaa..c6f1225 100644
> --- a/testcases/kernel/syscalls/chmod/chmod05.c
> +++ b/testcases/kernel/syscalls/chmod/chmod05.c
> @@ -177,7 +177,7 @@ int main(int ac, char **av)
>  			if ((PERMS & ~S_ISGID) != dir_mode) {
>  				tst_resm(TFAIL, "%s: Incorrect modes 0%03o, "
>  					 "Expected 0%03o", TESTDIR, dir_mode,
> -					 PERMS);
> +					 PERMS & ~S_ISGID);
>  			} else {
>  				tst_resm(TPASS,
>  					 "Functionality of chmod(%s, %#o) successful",
> @@ -241,12 +241,12 @@ void setup()
>  				strerror(errno));
>  	}

> 
> -	if (chown(TESTDIR, nobody_u->pw_uid, bin_group->gr_gid) == -1)
> +	if (chown(TESTDIR, nobody_u->pw_uid, nobody_u->pw_gid) == -1)
>  		tst_brkm(TBROK, cleanup, "Couldn't change owner of testdir: %s",
>  				strerror(errno));
> 
> -	/* change to nobody:nobody */
> -	if (setegid(nobody_u->pw_gid) == -1 ||
> +	/* change to nobody:bin */
> +	if (setegid(bin_group->gr_gid) == -1 ||
>  		 seteuid(nobody_u->pw_uid) == -1)
>  		tst_brkm(TBROK, cleanup, "Couldn't switch to nobody:nobody: %s",
>  				strerror(errno));


------------------------------------------------------------------------------
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
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] Issue observed with chmod05, fchmod05 test cases

[Subrata Modak]

On Tue, 2009-07-21 at 14:27 +0530, Sharyathi Nagesh wrote: 
> Garret
> 
> > 
> > Hi Yeehaw,
> >     1. You didn't provide sign-off, as noted in the DCO:
> > http://ltp.sourceforge.net/DCO.txt
> Excuse me for missing that out, if this patch format is okie I will resend it with the 
> sign-off included in it

Sharyathi, please resend this clean.

Regards--
Subrata

> >     2. This appears to be a legitimate documentation bug (at least as
> > far as the manpages for 2.6.29-r5 are concerned), because I can't find
> > a single reference to nobody in the manpage, as far as special
> > importance is concerned. Furthermore, looking at the OpenGroup's
> > documentation, I don't see anything there either:
> > http://www.opengroup.org/onlinepubs/000095399/functions/getgroups.html
> 
>   I am not very clear with what you are pointing at, but let me take a shot. bin and nobody 
> are 2 users used in the test case. I am not sure who or where it is getting created, but 
> what I did observe is that they don't have the same privileges. GID of bin is in the list of 
> supplementary group ids of root while nobody is not. If this is the case chmod/fchmod won't 
> clear S_IGSID bit of the file, as you can read from man page of chmod/fchmod.
>   Nobody won't be in any man page as this User was created by LTP, I suppose, to use in this 
> test case.
> Thanks
> Sharyathi N
> 
> 
> ------------------------------------------------------------------------------
> 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
> _______________________________________________
> Ltp-list mailing list
> Ltp-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ltp-list


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] Issue observed with chmod05, fchmod05 test cases

[Sharyathi Nagesh]

[-- Attachment #1: Type: text/plain, Size: 114 bytes --]

Subrata
> 
> Sharyathi, please resend this clean.
> 
Attaching it, with signed off added
Thanks
Sharyathi Nagesh


[-- Attachment #2: fix_supplementary_group_id_issue.patch --]
[-- Type: text/x-patch, Size: 1523 bytes --]

Signed-off-by: Sharyathi Nagesh <sharyath@in.ibm.com>

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: 355 bytes --]

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

[-- 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

Re: [LTP] Issue observed with chmod05, fchmod05 test cases

[Subrata Modak]

Sharyathi,

On Fri, 2009-07-31 at 07:08 +0530, Sharyathi Nagesh wrote:
> Subrata
> > 
> > Sharyathi, please resend this clean.
> > 
> Attaching it, with signed off added

This is good. But, what i wanted is:

1) Final and clear description of the purpose of the patch,
2) Signed-off-by: clause,
3) Patch itself,

Itś just like how you would resend a patch to LKML, saying:

[PATCH v2][RESEND] ...

Regards--
Subrata

> Thanks
> Sharyathi Nagesh
> 


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list