zsh-workers
 help / color / Atom feed
* P01privileged fails on CentOS/Fedora (a simple permission issue)
@ 2020-03-10  2:59 Jun T
  2020-03-10 17:26 ` Jun. T
  0 siblings, 1 reply; 8+ messages in thread
From: Jun T @ 2020-03-10  2:59 UTC (permalink / raw)
  To: zsh-workers

At least on CentOS/Fedora the default permission of a user's home
directory is rwx------. If I build/test zsh in a directory below
my home dir, say /home/takimoto/src/zsh/, P01privileged fails
because users with uid=1,2 can't read the necessary module(s).
Is this well known? I'm not sure whether this need be fixed.


Selecting unprivileged UID:EUID pair automatically
Selecting unprivileged GID:EGID pair automatically
Using unprivileged UID 1, EUID 2, GID 1, EGID 2
--- /tmp/zsh.ztst.15006/ztst.out	2020-03-10 11:20:22.808199407 +0900
+++ /tmp/zsh.ztst.15006/ztst.tout	2020-03-10 11:20:22.805199423 +0900
@@ -1,3 +1,3 @@
-1/1 off
-2/2 off
-1/2 on
+1/1
+2/2
+1/2
Test ./P01privileged.ztst failed: output differs from expected as shown above for:
  re_zsh $ruid $ruid -1 -1 'echo $UID/$EUID $options[privileged]'
  re_zsh $euid $euid -1 -1 'echo $UID/$EUID $options[privileged]'
  re_zsh $ruid $euid -1 -1 'echo $UID/$EUID $options[privileged]'
Error output:
zsh:1: failed to load module `zsh/parameter': /home/takimoto/src/zsh/Test/Modules/zsh/parameter.so: cannot open shared object file: Permission denied
(two more same errors)
Was testing: PRIVILEGED automatically enabled when RUID != EUID



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: P01privileged fails on CentOS/Fedora (a simple permission issue)
  2020-03-10  2:59 P01privileged fails on CentOS/Fedora (a simple permission issue) Jun T
@ 2020-03-10 17:26 ` Jun. T
  2020-03-11 20:06   ` dana
  0 siblings, 1 reply; 8+ messages in thread
From: Jun. T @ 2020-03-10 17:26 UTC (permalink / raw)
  To: zsh-workers


> 2020/03/10 11:59, I wrote
> 
> Is this well known? I'm not sure whether this need be fixed.

If we need to fix this, a possible quick fix would be to use a
relative path for MODULE_PATH. In the patch below the path
name 'Modules' is hard coded in re_zsh().


diff --git a/Test/P01privileged.ztst b/Test/P01privileged.ztst
index c54112bb6..9895e9bf6 100644
--- a/Test/P01privileged.ztst
+++ b/Test/P01privileged.ztst
@@ -113,7 +113,7 @@
       shift
     done
     re_exec "$1" "$2" "$3" "$4" $ZTST_exe $opts -fc \
-      "MODULE_PATH=${(q)MODULE_PATH}; ${(F)@[5,-1]}"
+      "MODULE_PATH=Modules; ${(F)@[5,-1]}"
   }
   #
   # Return one or more random unused UIDs



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: P01privileged fails on CentOS/Fedora (a simple permission issue)
  2020-03-10 17:26 ` Jun. T
@ 2020-03-11 20:06   ` dana
  2020-03-11 20:26     ` Bart Schaefer
  0 siblings, 1 reply; 8+ messages in thread
From: dana @ 2020-03-11 20:06 UTC (permalink / raw)
  To: Jun. T; +Cc: Zsh hackers list

On 10 Mar 2020, at 12:26, Jun. T <takimoto-j@kba.biglobe.ne.jp> wrote:
> If we need to fix this, a possible quick fix would be to use a
> relative path for MODULE_PATH. In the patch below the path
> name 'Modules' is hard coded in re_zsh().

Sorry, i hadn't considered this possibility. It definitely does need fixed
somehow.

I don't really like the idea of hard-coding the MODULE_PATH for one specific
test file; that feels brittle and weird. And we can't do it for the whole test
harness, because then if someone tried to cd into a temp directory or
something in a test it'd randomly break.

The only other workable alternative i can think of right now is to just make
P* files skip when they detect that they can't traverse to the test directory.

Not sure which is preferable. Maybe someone else has a better idea :/

dana


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: P01privileged fails on CentOS/Fedora (a simple permission issue)
  2020-03-11 20:06   ` dana
@ 2020-03-11 20:26     ` Bart Schaefer
  2020-03-12 18:11       ` dana
  0 siblings, 1 reply; 8+ messages in thread
From: Bart Schaefer @ 2020-03-11 20:26 UTC (permalink / raw)
  To: dana; +Cc: Jun. T, Zsh hackers list

On Wed, Mar 11, 2020 at 1:07 PM dana <dana@dana.is> wrote:
>
> I don't really like the idea of hard-coding the MODULE_PATH for one specific
> test file; that feels brittle and weird. And we can't do it for the whole test
> harness, because then if someone tried to cd into a temp directory or
> something in a test it'd randomly break.
>
> The only other workable alternative i can think of right now is to just make
> P* files skip when they detect that they can't traverse to the test directory.

What about reading the UID/GID of the directory to assign defaults of
ZSH_TEST_UNPRIVILEGED_UID and ZSH_TEST_UNPRIVILEGED_GID?

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: P01privileged fails on CentOS/Fedora (a simple permission issue)
  2020-03-11 20:26     ` Bart Schaefer
@ 2020-03-12 18:11       ` dana
  2020-03-13 10:16         ` Jun T
  0 siblings, 1 reply; 8+ messages in thread
From: dana @ 2020-03-12 18:11 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Jun. T, Zsh hackers list


On 11 Mar 2020, at 15:26, Bart Schaefer <schaefer@brasslantern.com> wrote:
> What about reading the UID/GID of the directory to assign defaults of
> ZSH_TEST_UNPRIVILEGED_UID and ZSH_TEST_UNPRIVILEGED_GID?

Thanks. Had to double-check this.

This will help, if (1) we use the directory owner for the EUID and (2) we get
rid of anything in the test file that tries to set the test shell's EUID to
something besides the owner or root.

Right now, only the very first test (the one that failed for Jun) does that. I
*think* it's probably fine to eliminate it, since it's a bit redundant in this
particular case... but it'll break again if we ever try to re-add a similar
check.

I guess i'm OK with that if everyone else is.

dana


diff --git a/Test/P01privileged.ztst b/Test/P01privileged.ztst
index c54112bb6..7c4a1be35 100644
--- a/Test/P01privileged.ztst
+++ b/Test/P01privileged.ztst
@@ -13,8 +13,13 @@
 # same requirements here.)
 #
 # If either of the aforementioned environment variables is not set, the test
-# script will try to pick the first two >0 IDs from the passwd/group databases
-# on the current system.
+# script will try to use the UID/GID of the test directory, if not 0, for the
+# two effective IDs. (This is intended to work around issues that might occur
+# when e.g. the test directory lives under a home directory with mode 0700.
+# Unfortunately, if this is the case, it will not be possible to use anything
+# besides the directory owner or root as the test shell's EUID -- maintainers
+# take note.) Otherwise, the script will pick the first >0 ID(s) from the
+# passwd/group databases on the current system.
 #
 # If either variable is set, the tests will run, but they will likely fail
 # without super-user privileges.
@@ -45,10 +50,12 @@
     euid=${ZSH_TEST_UNPRIVILEGED_UID##*:}
   else
     print -ru$ZTST_fd 'Selecting unprivileged UID:EUID pair automatically'
+    # See above for why we do this
+    zmodload -sF zsh/stat b:zstat && euid=${"$( zstat +uid -- $ZTST_testdir )":#0}
     local tmp=$( getent passwd 2> /dev/null || < /etc/passwd )
     # Note: Some awks require -v and its argument to be separate
-    ruid=$( awk -F:            '$3 > 0 { print $3; exit; }' <<< $tmp )
-    euid=$( awk -F: -v u=$ruid '$3 > u { print $3; exit; }' <<< $tmp )
+    ruid=$( awk -F: -v u=${euid:-0} '$3 > 0 && $3 != u { print $3; exit; }' <<< $tmp )
+    euid=${euid:-"$( awk -F: -v u=$ruid '$3 > u { print $3; exit; }' <<< $tmp )"}
   fi
   #
   if [[ -n $ZSH_TEST_UNPRIVILEGED_GID ]]; then
@@ -56,10 +63,12 @@
     egid=${ZSH_TEST_UNPRIVILEGED_GID##*:}
   else
     print -ru$ZTST_fd 'Selecting unprivileged GID:EGID pair automatically'
+    # See above again -- this shouldn't have the same impact as the UID, though
+    zmodload -sF zsh/stat b:zstat && egid=${"$( zstat +gid -- $ZTST_testdir )":#0}
     local tmp=$( getent group 2> /dev/null || < /etc/group )
     # Note: Some awks require -v and its argument to be separate
-    rgid=$( awk -F:            '$3 > 0 { print $3; exit; }' <<< $tmp )
-    egid=$( awk -F: -v g=$rgid '$3 > g { print $3; exit; }' <<< $tmp )
+    rgid=$( awk -F: -v g=${egid:-0} '$3 > 0 && $3 != g { print $3; exit; }' <<< $tmp )
+    egid=${egid:="$( awk -F: -v g=$rgid '$3 > g { print $3; exit; }' <<< $tmp )"}
   fi
   #
   [[ $ruid/$euid == <1->/<1-> && $ruid != $euid ]] || ruid= euid=
@@ -134,11 +143,9 @@
 
 %test
 
-  re_zsh $ruid $ruid -1 -1 'echo $UID/$EUID $options[privileged]'
   re_zsh $euid $euid -1 -1 'echo $UID/$EUID $options[privileged]'
   re_zsh $ruid $euid -1 -1 'echo $UID/$EUID $options[privileged]'
 0q:PRIVILEGED automatically enabled when RUID != EUID
->$ruid/$ruid off
 >$euid/$euid off
 >$ruid/$euid on
 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: P01privileged fails on CentOS/Fedora (a simple permission issue)
  2020-03-12 18:11       ` dana
@ 2020-03-13 10:16         ` Jun T
  2020-03-13 14:19           ` dana
  0 siblings, 1 reply; 8+ messages in thread
From: Jun T @ 2020-03-13 10:16 UTC (permalink / raw)
  To: zsh-workers


> 2020/03/13 3:11, dana <dana@dana.is> wrote:
> 
> 
> On 11 Mar 2020, at 15:26, Bart Schaefer <schaefer@brasslantern.com> wrote:
>> What about reading the UID/GID of the directory to assign defaults of
>> ZSH_TEST_UNPRIVILEGED_UID and ZSH_TEST_UNPRIVILEGED_GID?
> 
> Thanks. Had to double-check this.
> 
> This will help, if (1) we use the directory owner for the EUID and (2) we get
> rid of anything in the test file that tries to set the test shell's EUID to
> something besides the owner or root.
> 
> Right now, only the very first test (the one that failed for Jun) does that. I
> *think* it's probably fine to eliminate it, since it's a bit redundant in this
> particular case... but it'll break again if we ever try to re-add a similar
> check.

With the patch P01 (with sudo) succeeds on Fedora.

Personally I feel it's simpler to use relative path, but have no objection
to using UID of ZTST_tesdir.

# If you don't like hard-coding the directory name we can pass it from
# Test/Makefile.in, via a variable like ZTST_moddir, to ztst.zsh (line 38)
# and use it in P01privileged.ztst.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: P01privileged fails on CentOS/Fedora (a simple permission issue)
  2020-03-13 10:16         ` Jun T
@ 2020-03-13 14:19           ` dana
  2020-03-17  5:34             ` Jun T
  0 siblings, 1 reply; 8+ messages in thread
From: dana @ 2020-03-13 14:19 UTC (permalink / raw)
  To: Jun T; +Cc: Zsh hackers list

On 13 Mar 2020, at 05:16, Jun T <takimoto-j@kba.biglobe.ne.jp> wrote:
> Personally I feel it's simpler to use relative path, but have no objection
> to using UID of ZTST_tesdir.
>
> # If you don't like hard-coding the directory name we can pass it from
> # Test/Makefile.in, via a variable like ZTST_moddir, to ztst.zsh (line 38)
> # and use it in P01privileged.ztst.

You're definitely right that it's simpler that way.

I'm less worried about the name of the directory than about its location,
which i'm not sure is in the test file's purview. If it's alright for it to
make the assumption that the module directory is under $ZTST_dir then we could
simply use ${module_path#$ZTST_dir/}. I would be OK with that compromise.

Though — and i'm absolutely rationalising after the fact now — using the UID
of the test directory will also take care of the case where the repo itself
has been cloned with umask 027 or 077 (unless it's owned by root...).

Does that justify the complexity? I don't know

dana


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: P01privileged fails on CentOS/Fedora (a simple permission issue)
  2020-03-13 14:19           ` dana
@ 2020-03-17  5:34             ` Jun T
  0 siblings, 0 replies; 8+ messages in thread
From: Jun T @ 2020-03-17  5:34 UTC (permalink / raw)
  To: zsh-workers


> 2020/03/13 23:19, dana <dana@dana.is> wrote:
> 
> I'm less worried about the name of the directory than about its location,
> which i'm not sure is in the test file's purview.

I've been mostly worried about using a hard-coded name 'Modules' in three
different files: Test/Makefile.in, ztst.zsh and P01privileged.ztst.

> If it's alright for it to
> make the assumption that the module directory is under $ZTST_dir

Yes, unless someone modifies ztst.zsh (lines 38 and 60).

> Though — and i'm absolutely rationalising after the fact now — using the UID
> of the test directory will also take care of the case where the repo itself
> has been cloned with umask 027 or 077 (unless it's owned by root...).

If we need to take account of a possibility that the 'Test' directory itself is
not world readable/searchable, then, yes, we need to use the UID of its owner.

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, back to index

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-10  2:59 P01privileged fails on CentOS/Fedora (a simple permission issue) Jun T
2020-03-10 17:26 ` Jun. T
2020-03-11 20:06   ` dana
2020-03-11 20:26     ` Bart Schaefer
2020-03-12 18:11       ` dana
2020-03-13 10:16         ` Jun T
2020-03-13 14:19           ` dana
2020-03-17  5:34             ` Jun T

zsh-workers

Archives are clonable: git clone --mirror http://inbox.vuxu.org/zsh-workers

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.workers


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git