All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH v4] syscalls/prctl06: New test for prctl() with PR_{SET, GET}_NO_NEW_PRIVS
Date: Tue, 16 Jul 2019 17:32:12 +0800	[thread overview]
Message-ID: <5D2D999C.3010601@cn.fujitsu.com> (raw)
In-Reply-To: <20190716090908.GA12815@rei.lan>


> Hi!
> Pushed with two changes, thanks.
>
>
> diff --git a/testcases/kernel/syscalls/prctl/prctl06.c b/testcases/kernel/syscalls/prctl/prctl06.c
> index eafbedfef..0e1274a2a 100644
> --- a/testcases/kernel/syscalls/prctl/prctl06.c
> +++ b/testcases/kernel/syscalls/prctl/prctl06.c
> @@ -81,8 +81,8 @@ static void setup(void)
>
>   	SAFE_CP(TESTBIN, TEST_REL_BIN_DIR);
>
> -	SAFE_CHMOD(BIN_PATH, SUID_MODE);
>   	SAFE_CHOWN(BIN_PATH, 0, 0);
> +	SAFE_CHMOD(BIN_PATH, SUID_MODE);
>
>   	TEST(prctl(PR_GET_NO_NEW_PRIVS, 0, 0, 0, 0));
>   	if (TST_RET == 0) {
>
> This is actually important fix, you have to set the SUID bits last since
> they are cleared if you change owner of the file.
Hi Cyril

OK. I learn a lot from this case. Thanks for kindly reply.

>
> diff --git a/testcases/kernel/syscalls/prctl/prctl06.h b/testcases/kernel/syscalls/prctl/prctl06.h
> index 72f9c4e5a..f5c66e809 100644
> --- a/testcases/kernel/syscalls/prctl/prctl06.h
> +++ b/testcases/kernel/syscalls/prctl/prctl06.h
> @@ -25,12 +25,14 @@
>   #define BIN_PATH           MNTPOINT"/"TESTBIN
>   #define SUID_MODE          (S_ISUID|S_ISGID|S_IXUSR|S_IXGRP|S_IXOTH)
>
> -static int flag = 1;
> -
>   void check_proc_field(int val, char *name)
>   {
> +	static int flag = 1;
>   	int field = 0;
>
> +	if (!flag)
> +		return;
> +
>   	TEST(FILE_LINES_SCANF(PROC_STATUS, "NoNewPrivs:%d",&field));
>   	if (TST_RET == 1) {
>   		tst_res(TCONF,
> @@ -57,8 +59,8 @@ void check_no_new_privs(int val, char *name)
>   		tst_res(TFAIL,
>   			"%s prctl(PR_GET_NO_NEW_PRIVS) expected %d got %ld",
>   			name, val, TST_RET);
> -	if (flag)
> -		check_proc_field(val, name);
> +
> +	check_proc_field(val, name);
>   }
>
>   #endif
>
> This is merely cosmetic and moves the flag to the function so that it's
> not global.
Yes. static local variable is better.





      reply	other threads:[~2019-07-16  9:32 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20190715154945.GA28618@rei.lan>
2019-07-16  5:37 ` [LTP] [PATCH v4] syscalls/prctl06: New test for prctl() with PR_{SET, GET}_NO_NEW_PRIVS Yang Xu
2019-07-16  9:09   ` Cyril Hrubis
2019-07-16  9:32     ` Yang Xu [this message]

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=5D2D999C.3010601@cn.fujitsu.com \
    --to=xuyang2018.jy@cn.fujitsu.com \
    --cc=ltp@lists.linux.it \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.