P01privileged fails on CentOS/Fedora (a simple permission issue)

P01privileged fails on CentOS/Fedora (a simple permission issue)

[Jun T]

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

Re: P01privileged fails on CentOS/Fedora (a simple permission issue)

[Jun. T]

> 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

Re: P01privileged fails on CentOS/Fedora (a simple permission issue)

[dana]

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

Re: P01privileged fails on CentOS/Fedora (a simple permission issue)

[Bart Schaefer]

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?

Re: P01privileged fails on CentOS/Fedora (a simple permission issue)

[dana]

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
 

Re: P01privileged fails on CentOS/Fedora (a simple permission issue)

[Jun T]

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

Re: P01privileged fails on CentOS/Fedora (a simple permission issue)

[dana]

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

Re: P01privileged fails on CentOS/Fedora (a simple permission issue)

[Jun T]

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

Re: P01privileged fails on CentOS/Fedora (a simple permission issue)

[dana]

On 17 Mar 2020, at 00:34, Jun T <takimoto-j@kba.biglobe.ne.jp> wrote:
> 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.

Sorry for letting this sit, occupied with other things

I decided to go with the more complicated option. Hopefully it'll account for
any similar issues and i'll not have to mess with this file again

dana