* 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; 9+ 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] 9+ 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; 9+ 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] 9+ 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; 9+ 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] 9+ 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; 9+ 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] 9+ 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; 9+ 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] 9+ 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; 9+ 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] 9+ 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; 9+ 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] 9+ 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 2020-04-01 22:35 ` dana 0 siblings, 1 reply; 9+ 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] 9+ messages in thread
* Re: P01privileged fails on CentOS/Fedora (a simple permission issue) 2020-03-17 5:34 ` Jun T @ 2020-04-01 22:35 ` dana 0 siblings, 0 replies; 9+ messages in thread From: dana @ 2020-04-01 22:35 UTC (permalink / raw) To: Jun T; +Cc: Zsh hackers list 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-04-01 22:35 UTC | newest] Thread overview: 9+ 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 2020-04-01 22:35 ` dana
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).