s6-log can create current with 640?

s6-log can create current with 640?

[Dewayne Geraghty]

Is there any way to tell s6-log to set the mode to ./current to
something other than 644?  640 is preferred?

For example: I write to the logdir /var/log/httpd/error which has privs:

/var/log/http
drwx------  2 uucp  uucp   1.0K Oct 23 12:37 error/

Within /var/log/httpd/error
-rwxr--r--  1 uucp  uucp   190K Oct 23 12:37 @400000005dafaf1b180d862c.s*
-rw-r-----  1 uucp  uucp     0B Oct 23 12:37 state
-rw-r--r--  1 uucp  uucp     0B Oct 23 12:37 current

I did try umask 037 but that just broke the pipe.

All my log files are of this form
#!/usr/local/bin/execlineb -P
s6-setuidgid uucp
redirfd -r 0 /services/ntp/fifo
/usr/local/bin/s6-log -b n28 r7000 s200000 S7000000 !"/usr/bin/xz -7q"
/var/log/ntpd

This is a big deal as I'm about to move my audit processing under s6-rc.

(Aside: Actually I write to a fifo and then redirfd for s6-log to pick
up the content and manage the log files.  All works very nicely :) )

Re: s6-log can create current with 640?

[Colin Booth]

On Wed, Oct 23, 2019 at 01:27:24PM +1100, Dewayne Geraghty wrote:
> Is there any way to tell s6-log to set the mode to ./current to
> something other than 644?  640 is preferred?
> 
> For example: I write to the logdir /var/log/httpd/error which has privs:
> 
> /var/log/http
> drwx------  2 uucp  uucp   1.0K Oct 23 12:37 error/
> 
> Within /var/log/httpd/error
> -rwxr--r--  1 uucp  uucp   190K Oct 23 12:37 @400000005dafaf1b180d862c.s*
> -rw-r-----  1 uucp  uucp     0B Oct 23 12:37 state
> -rw-r--r--  1 uucp  uucp     0B Oct 23 12:37 current
> 
> I did try umask 037 but that just broke the pipe.
> 
> All my log files are of this form
> #!/usr/local/bin/execlineb -P
> s6-setuidgid uucp
> redirfd -r 0 /services/ntp/fifo
> /usr/local/bin/s6-log -b n28 r7000 s200000 S7000000 !"/usr/bin/xz -7q"
> /var/log/ntpd
> 
> This is a big deal as I'm about to move my audit processing under s6-rc.
> 
> (Aside: Actually I write to a fifo and then redirfd for s6-log to pick
> up the content and manage the log files.  All works very nicely :) )

I know it isn't sexy but directory restrictions are good enough in this
situation. In your case, only the uucp user is allowed to descend into
that directory to start with so as long as that guarantee stays in place
the file permissions shouldn't matter. In fact, 640 is *more* permissive
than the parent directory due to the ability for accounts in the uucp
group to observe the file, even if they can't get to the directory to do
it. 

Cheers!
-- 
Colin Booth

Re: s6-log can create current with 640?

[Dewayne Geraghty]

Thank-you, Colin.

My brain turned to mush integrating logging with fifo queues across
multiple jails (aka very lightweight VMs) and disjoint users (userA
writes, userB reads).  Unfortunately they're across various jailed
systems, so the s6 fifo tools aren't applicable.  I appreciate your
advice, and yes, if there was anyone in the uucp group, I could be
labelled "overly permissive"!  ;^)

Kind regards, Dewayne.
PS I've gotten to like s6, it helped me discover a "workaround" for an
aslr issue with ntp, which under normal circumstance I would've given up.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241421

Re: s6-log can create current with 640?

[Jonathan de Boyne Pollard]

Dewayne Geraghty:
> I did try umask 037 but that just broke the pipe.

That was probably because you were using the wrong umask tool.  It has 
to be the chain-loading one in a nosh or an execlineb script.

% cat /var/sv/deluged/service/run
#!/bin/nosh
#Deluge BitTorrent client
envuidgid -- deluge
userenv-fromenv
umask 037
setuidgid -- deluge
deluged --do-not-daemonize
%

* http://jdebp.uk./Softwares/nosh/guide/commands/umask.xml

* http://skarnet.org/software/execline/umask.html

Re: s6-log can create current with 640?

[Dewayne Geraghty]

Thanks Jonathon.  Both attempts were within the execlineb context, so I
assume that umask was correctly employed ;).  I tried

My initial attempt

#!/usr/local/bin/execlineb -P
s6-setuidgid uucp
redirfd -r 0 /services/ntp/fifo
umask 037
/usr/local/bin/s6-log -b n14 r7000 s100000 S3000000 !"/usr/bin/xz -7q"
/var/log/ntpd

which results in notice of "# echo: write: Broken pipe"; the ntp process
properly starts but there is no ntp logging process.

---
The usual flow is
echo: write: Broken pipe
...

and in quick succession (<1 sec):

# ps -axww | grep ntpd
28869  -  Rs         0:00.00 s6-setuidgid uucp redirfd -r 0
/service/fifo umask 037 /usr/local/bin/s6-log -b n14 r7000 s100000
S3000000 !/usr/bin/xz -7q /var/log/ntpd

# ps -axww | grep ntpd
29457  -  Ss         0:00.03 /usr/local/sbin/ntpd -c /etc/ntp.conf -u
ntpd -x -G --nofork

and /var/log/ntpd folder is empty (with mode rwx------)
---

If I move umask up one line (before redirfd), the logging process
doesn't start; and blocks the start of ntp.  There is a dependency
relationship ntp-log <- ntp  so this is expected.

I was surprised that umask didn't work, but not overly concerned; as
Colin, quite rightly, pointed to my directory permissions as being
adequate.  Now to migrate sendmail and its milters...

Regards, Dewayne

Re: s6-log can create current with 640?

[Laurent Bercot]

>My initial attempt
>
>#!/usr/local/bin/execlineb -P
>s6-setuidgid uucp
>redirfd -r 0 /services/ntp/fifo
>umask 037
>/usr/local/bin/s6-log -b n14 r7000 s100000 S3000000 !"/usr/bin/xz -7q"
>/var/log/ntpd

  Hi Dewayne,

  - Is there a reason why you're using a manually created fifo instead
of the built-in logging facility offered by s6-svscan? You could tell
ntpd to log to /dev/stdout, and have the logger in a ntpd/log service
directory, and your logs would automatically be available on your
logger's stdin.

  - About umask: that's very strange. Can you strace, or ktrace, or
whatever tool gives you a list of system calls, the script? It will
show exactly what's going on.

--
  Laurent

Re: s6-log can create current with 640?

[Dewayne Geraghty]

Laurent, I've embedded responses:

On 24/10/2019 10:58 am, Laurent Bercot wrote:
>> My initial attempt
>>
>> #!/usr/local/bin/execlineb -P
>> s6-setuidgid uucp
>> redirfd -r 0 /services/ntp/fifo
>> umask 037
>> /usr/local/bin/s6-log -b n14 r7000 s100000 S3000000 !"/usr/bin/xz -7q"
>> /var/log/ntpd
> 
>  Hi Dewayne,
> 
>  - Is there a reason why you're using a manually created fifo instead
> of the built-in logging facility offered by s6-svscan? You could tell
> ntpd to log to /dev/stdout, and have the logger in a ntpd/log service
> directory, and your logs would automatically be available on your
> logger's stdin.
> 
That's really testing my memory! I recall using the producer/consumer
pair; as well as s6-trig-notify and s6-ftrig-listen. But at the end of
the day, processes like apache have multiple log files, and in my case 5
access log files and one error log.  So either I use one aggregated log
(input) with multiple regex expressions in an s6-log statement (which I
was advised against doing) or multiple
s6-log for each input, which I chose.

In addition the log content need to traverse different VM contexts,
where I usually use lo0; but in this case, a nullfs and fifo was the
better choice per some early benchmarks (via the wrk tool).

Re: ntp and its log file?  Yes within a single machine context, one
process writes to stdout and another takes that as input for s6-log to
handle, makes sense (and easy).  However the "logger" will relocate to a
separate VM, when unrelated problems with an ASLR enabled ntpd are
fixed.  Again a nullfs and fifo are sufficient - one VM writes to the
fifo, a different user in a different VM reads & processes the log via
s6-log.

Aside: If someone isn't familiar with FreeBSD, it can be hard to get a
handle on FreeBSD jails, its a bit more than a simple chroot.  I think
its reasonable to consider them as very lightweight VMs.  Each can have
separate security levels, shared memory; multiple network interfaces and
IP addresses etc; all sharing the one kernel.  The only con, is that the
first IP address is treated as routable and localhost points to it.


>  - About umask: that's very strange. Can you strace, or ktrace, or
> whatever tool gives you a list of system calls, the script? It will
> show exactly what's going on.
> 

Apologies for the delay. Needed to rebuild the kernel to enable ktrace.

Results for umask
rm -f /tmp/t1 ; /usr/local/bin/execlineb -Pc 'redirfd -w 1 /tmp/t1 umask
037 echo hello' ; echo $? ; ls -l /tmp/t1
0
-rw-r-----  1 root  wheel  0 25 Oct 18:33 /tmp/t1

rm -f /tmp/t1 ; /usr/local/bin/execlineb -Pc 'redirfd -w 1 /tmp/t1 umask
023 echo hello' ; echo $? ; ls -l /tmp/t1
0
-rw-r-----  1 root  wheel  0 25 Oct 18:36 /tmp/t1

I've placed the ktrace's dumpfile in txt format so its readable for you at
http://www.heuristicsystems.com/s6-umask/t1.kdump

The OS umask is 027.

I also tried what I thought was the more logical
# rm -f /tmp/t1 ; /usr/local/bin/execlineb -Pc 'umask 033 redirfd -w 1
/tmp/t1 echo hello' ; echo $? ; ls -l /tmp/t1
0
ls: /tmp/t1: No such file or directory

This ktrace is
http://www.heuristicsystems.com/s6-umask/t1-umask-redirfd.kdump

I think the relevant lines are
   276 sh       CALL  umask(0)
   276 sh       RET   umask 23/0x17
   276 sh       CALL  umask(027<S_IWGRP|S_IROTH|S_IWOTH|S_IXOTH>)
   276 sh       RET   umask 0
   276 sh       CALL  umask(033<S_IWGRP|S_IXGRP|S_IWOTH|S_IXOTH>)
   276 sh       RET   umask 23/0x17
   276 sh       CALL  read(0xa,0x104c9d0,0x400)

Platform details:
# uname -pivKU; cc -v ; ld -v
FreeBSD 12.1-STABLE #5 r353671M: Fri Oct 25 09:12:32 AEDT 2019  amd64
hqdev-amd64-smp-vga 1201500 1201500
FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on
LLVM 8.0.1)
Target: x86_64-unknown-freebsd12.1
Thread model: posix
InstalledDir: /usr/bin
LLD 8.0.1 (FreeBSD 366581-1200008) (compatible with GNU linkers)

If there is anything I can do to assist please let me know.  (Though I
havent worked in C since 1990...)

Kind regards, Dewayne

Re: s6-log can create current with 640?

[Guillermo]

El vie., 25 oct. 2019 a las 5:22, Dewayne Geraghty escribió:
>
> Results for umask
> rm -f /tmp/t1 ; /usr/local/bin/execlineb -Pc 'redirfd -w 1 /tmp/t1 umask
> 037 echo hello' ; echo $? ; ls -l /tmp/t1
> [...]
> I've placed the ktrace's dumpfile in txt format so its readable for you at
> http://www.heuristicsystems.com/s6-umask/t1.kdump
 42180 execlineb CALL  execve(0x7fffffffc770,0x7fffffffc830,0x7fffffffea40)
 42180 execlineb NAMI  "/sbin/redirfd"
 42180 execlineb RET   execve -1 errno 2 No such file or directory
 42180 execlineb CALL  execve(0x7fffffffc770,0x7fffffffc830,0x7fffffffea40)
 42180 execlineb NAMI  "/bin/redirfd"
 42180 execlineb RET   execve -1 errno 2 No such file or directory
 42180 execlineb CALL  execve(0x7fffffffc760,0x7fffffffc830,0x7fffffffea40)
 42180 execlineb NAMI  "/usr/sbin/redirfd"
 42180 execlineb RET   execve -1 errno 2 No such file or directory
 42180 execlineb CALL  execve(0x7fffffffc760,0x7fffffffc830,0x7fffffffea40)
 42180 execlineb NAMI  "/usr/bin/redirfd"
 42180 execlineb RET   execve -1 errno 2 No such file or directory
 42180 execlineb CALL  execve(0x7fffffffc760,0x7fffffffc830,0x7fffffffea40)
 42180 execlineb NAMI  "/usr/local/sbin/redirfd"
 42180 execlineb RET   execve -1 errno 2 No such file or directory
 42180 execlineb CALL  execve(0x7fffffffc760,0x7fffffffc830,0x7fffffffea40)
 42180 execlineb NAMI  "/usr/local/bin/redirfd"
 42180 execlineb NAMI  "/libexec/ld-elf.so.1"
 42180 redirfd  RET   execve JUSTRETURN

> I also tried what I thought was the more logical
> # rm -f /tmp/t1 ; /usr/local/bin/execlineb -Pc 'umask 033 redirfd -w 1
> /tmp/t1 echo hello' ; echo $? ; ls -l /tmp/t1
> [...]
> This ktrace is
> http://www.heuristicsystems.com/s6-umask/t1-umask-redirfd.kdump
   276 execlineb CALL  execve(0x7fffffffc770,0x7fffffffc830,0x7fffffffea40)
   276 execlineb NAMI  "/usr/bin/umask"
   276 execlineb NAMI  "/bin/sh"
   276 execlineb NAMI  "/libexec/ld-elf.so.1"
   276 sh       RET   execve JUSTRETURN
[...]
   276 sh       CALL
openat(AT_FDCWD,0x7fffffffed10,0x100000<O_RDONLY|O_CLOEXEC>)
   276 sh       NAMI  "/usr/bin/umask"
   276 sh       RET   openat 3
   276 sh       CALL  fcntl(0x3,F_DUPFD_CLOEXEC,0xa)
   276 sh       RET   fcntl 10/0xa
   276 sh       CALL  close(0x3)
[...]
   276 sh       CALL  read(0xa,0x104c9d0,0x400)
   276 sh       GIO   fd 10 read 160 bytes
       "#!/bin/sh
        # $FreeBSD: stable/12/usr.bin/alias/generic.sh 151635
2005-10-24 22:32:19Z cperciva $
        # This file is in the public domain.
        builtin ${0##*/} ${1+"$@"}
       "
   276 sh       RET   read 160/0xa0

Let me guess: the value of PATH is
/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin,
execline's chain loading umask is in /usr/local/bin, and FreeBSD
happens to have an 'umask' shell script in /usr/bin. If that is
correct, then you'll have to either use the absolute pathname
/usr/local/bin/umask in the execlineb chain, or run it with a PATH in
which /usr/local/bin comes before /usr/bin.

G.

Re: s6-log can create current with 640?

[Dewayne Geraghty]

On 26/10/2019 4:06 am, Guillermo wrote:
...
> Let me guess: the value of PATH is
> /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin,
> execline's chain loading umask is in /usr/local/bin, and FreeBSD
> happens to have an 'umask' shell script in /usr/bin. If that is
> correct, then you'll have to either use the absolute pathname
> /usr/local/bin/umask in the execlineb chain, or run it with a PATH in
> which /usr/local/bin comes before /usr/bin.
> 
> G.
> 

Irk!  Thank-you Guillermo, your guess is correct.
I'd mistakenly assumed execlineb knew where its friends were; though in
hindsight its a bit much to assume that execlineb internally changes the
PATH.

This works correctly
# rm /tmp/t1 ; setenv PATH
"/usr/local/bin:/bin:/sbin:/usr/sbin:/usr/bin" ; printenv | grep -i path
; ktrace -f /tmp/t1-pathok-umaskfirst \
/usr/local/bin/execlineb -Pc 'export path "/usr/local/bin" umask 033
redirfd -w 1 /tmp/t1 echo hello' ; echo $? ; ls -l /tmp/t1

PATH=/usr/local/bin:/bin:/sbin:/usr/sbin:/usr/bin
0
-rw-r--r--  1 root  wheel  6 26 Oct 11:19 /tmp/t1

as does
/usr/local/bin/execlineb -Pc '/usr/local/bin/umask 033
/usr/local/bin/redirfd -w 1 /tmp/t1 echo hello'

Unfortunately it seems that the path can't be set within execlineb context.

I tried both "path" and "PATH" in the following export and envfile examples.

export

/usr/local/bin/execlineb -Pc '/usr/local/bin/export PATH /usr/local/bin
umask 033 redirfd -w 1 /tmp/t1 echo hello' ; echo $? ; ls -l /tmp/t1
rm: /tmp/t1: No such file or directory
PATH=/bin:/sbin:/usr/sbin:/usr/bin
0
ls: /tmp/t1: No such file or directory

envfile

/usr/local/bin/execlineb -Pc '/usr/local/bin/envfile /tmp/e umask 035
redirfd -w 1 /tmp/t1 echo hello' ; echo $? ; ls -l /tmp/t1
where /tmp/e
path = /usr/local/bin:/bin:/sbin:/usr/sbin:/usr/bin

I've moved the various kdumps into
http://www.heuristicsystems.com/s6-umask/

However I don't think there is a problem with export as
/usr/local/bin/execlineb -Pc 'export T1 /tmp/t1 umask 033 importas T1v
T1 redirfd -w 1 $T1v echo hello'
works correctly, but envfile doesn't; might be worth a look. (?)

Kind regards, Dewayne

Re: s6-log can create current with 640?

[Laurent Bercot]

>I'd mistakenly assumed execlineb knew where its friends were; though in
>hindsight its a bit much to assume that execlineb internally changes the
>PATH.

The real question is, why is there a "umask" binary that's not the one
from execline? Non-chainloading non-builtin umask is nonsense, just
like non-chainloading non-builtin cd.


>Unfortunately it seems that the path can't be set within execlineb context.

Of course it can. What's happening is that both export and envfile
set the PATH *on execution of the next command*, so the command that's
right after them will still be searched with the old PATH. In other 
words:

"export PATH /usr/local/bin umask 033 echo blah" will not work, because
umask will still be searched for in the old PATH (but echo would be
searched in the new PATH), but
"export PATH /usr/local/bin exec umask 033 echo blah" will work, because
exec is searched in the old PATH and umask is searched in the new PATH.

(exec is an execline nop that can be useful in those cases, if you
don't have another command to put between the export PATH and the
command you need to search in the new PATH.)

--
Laurent

Re: s6-log can create current with 640?

[Dewayne Geraghty]

Hi Laurent,  Answers embedded

On 26/10/2019 4:27 pm, Laurent Bercot wrote:
>> I'd mistakenly assumed execlineb knew where its friends were; though in
>> hindsight its a bit much to assume that execlineb internally changes the
>> PATH.
> 
> The real question is, why is there a "umask" binary that's not the one
> from execline? Non-chainloading non-builtin umask is nonsense, just
> like non-chainloading non-builtin cd.
> 

I can only shed a ray of light, though this /usr/bin/umask has been
around for some time.  I fired up an old FreeBSD 9.2 system that has it.
Content being:

#!/bin/sh
# $FreeBSD: stable/9/usr.bin/alias/generic.sh 151635 2005-10-24
22:32:19Z cperciva $
# This file is in the public domain.
builtin ${0##*/} ${1+"$@"}

which is the same as 12.1.  Why? I can only refer to src logs:

...
------------------------------------------------------------------------
r151635 | cperciva | 2005-10-25 08:32:19 +1000 (Tue, 25 Oct 2005) | 10 lines

Use the "builtin" shell function to make sure that the requested
command is handled as a shell function.  This avoids the following
peculiar behaviour when /usr/bin is on a case-insensitive filesystem:
    # READ foo
(... long pause, depending upon the amount of swap space available ...)
    sh: Resource temporarily unavailable.

...
------------------------------------------------------------------------
r100200 | wollman | 2002-07-17 08:16:05 +1000 (Wed, 17 Jul 2002) | 5 lines

A little bit more thought has resulted in a generic script which can
implement any of the useless POSIX-required ``regular shell builtin''
utilities, saving one frag and one inode each.  The script moves to
usr.bin/alias which is alphabetically the first of these commands.

------------------------------------------------------------------------

the last entry before the cvs logs were transferred to svn.


Examining the Makefile/usr/src/usr.bin/alias/Makefile
# $FreeBSD: stable/12/usr.bin/alias/Makefile 284255 2015-06-11 04:22:17Z
sjg $

SCRIPTS=generic.sh
SCRIPTSNAME=alias

LINKS=  ${BINDIR}/alias ${BINDIR}/bg \
        ${BINDIR}/alias ${BINDIR}/cd \
        ${BINDIR}/alias ${BINDIR}/command \
        ${BINDIR}/alias ${BINDIR}/fc \
        ${BINDIR}/alias ${BINDIR}/fg \
        ${BINDIR}/alias ${BINDIR}/getopts \
        ${BINDIR}/alias ${BINDIR}/hash \
        ${BINDIR}/alias ${BINDIR}/jobs \
        ${BINDIR}/alias ${BINDIR}/read \
        ${BINDIR}/alias ${BINDIR}/type \
        ${BINDIR}/alias ${BINDIR}/ulimit \
        ${BINDIR}/alias ${BINDIR}/umask \
        ${BINDIR}/alias ${BINDIR}/unalias \
        ${BINDIR}/alias ${BINDIR}/wait

and yes they exist in /usr/bin/

From tcsh
# which cd
cd: shell built-in command.

From sh
# which echo
/bin/echo

Ok - that's done my head in.
> 
>> Unfortunately it seems that the path can't be set within execlineb
>> context.
> 
> Of course it can. What's happening is that both export and envfile
> set the PATH *on execution of the next command*, so the command that's
> right after them will still be searched with the old PATH. In other words:
> 
> "export PATH /usr/local/bin umask 033 echo blah" will not work, because
> umask will still be searched for in the old PATH (but echo would be
> searched in the new PATH), but
> "export PATH /usr/local/bin exec umask 033 echo blah" will work, because
> exec is searched in the old PATH and umask is searched in the new PATH.
> 
> (exec is an execline nop that can be useful in those cases, if you
> don't have another command to put between the export PATH and the
> command you need to search in the new PATH.)
>

Thank-you, the explanation helps.  I guess through bad experiences with
(non-execline) exec, I avoid it unless I really do want to transfer
control to it.

I think with this example
# rm -v /tmp/t1 ; setenv PATH
/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin ; execlineb -Pc 'importas
op PATH emptyenv export PATH /usr/local/bin:$op exec umask 002 redirfd
-w 1 /tmp/t1 echo blah4' ; /bin/ls -l t1 ; cat /tmp/t1
/tmp/t1
-rw-rw-r--  1 root  wheel  6 26 Oct 18:02 t1
blah4

Due to the above discussion around umask, I will have to consider either
adding to my execline scripts :(
importas op PATH
emptyenv
export PATH /usr/local/bin:$op

or explicit paths as needed.

Thank-you to the contributors for your patience.

Re: s6-log can create current with 640?

[Laurent Bercot]

>A little bit more thought has resulted in a generic script which can
>implement any of the useless POSIX-required ``regular shell builtin''

Yeah, so it's another one of those functions that only make sense as
shell builtins but that are still also implemented as external commands.
Beats me why systems insist on having those commands, since they're 
never
invoked and are an utter waste of space.

The only solution to your predicament is to make sure that the location
of execline's umask binary in your PATH appears *before* the location
of the system umask binary. Normally that's the case, since the execline
utilities are in /usr/local/bin and the system utilities are in 
/usr/bin;
you should _always_ have /usr/local/bin before /usr/bin in your PATH,
because programs installed by the administrator should always override
programs installed by default by the distributor.

For some reason it's not the case in the execline script you're 
invoking;
you need to make sure your supervision tree is invoked with a proper 
PATH.

(Also, I'll have to write a posix-umask command in the same way as
posix-cd, but that's totally unrelated to your problem and wouldn't fix
your PATH issue.)

--
Laurent

Re: s6-log can create current with 640?

[Jonathan de Boyne Pollard]

Laurent Bercot:
> The real question is, why is there a "umask" binary that's not the one 
> from execline? Non-chainloading non-builtin umask is nonsense, just 
> like non-chainloading non-builtin cd. 

Not quite.  People find uses for these things, and as the SUS rationale 
points out, for every potentially useless external equivalent of a 
(non-special) built-in command someone has come up with an arcane actual 
use for it.  Even "cd".

* 
https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap01.html#tag_23_01_07

* https://unix.stackexchange.com/q/50058/5132

The POSIX model is therefore that all non-special built-ins are also 
available as executables; or, rather, that all of the standard utilities 
that are not special built-ins are simply *available* (via execvp(), 
find -exec, env, and *all of the other* ways that standard utilities can 
be invoked), and whether they are built-in or not, to a shell or 
otherwise, is an implementation detail as far as actually invoking the 
utility is concerned.  (Very few shells truly conform to this, but the 
Watanabe shell largely does in its non-native mode.)

* https://unix.stackexchange.com/q/347188/5132

* https://unix.stackexchange.com/q/496259/5132

nosh, not being a shell, is not bound by this.  Its built-ins are found 
before a PATH search is enacted.  So it actually does what M. Geraghty 
mistakenly thought execline was doing.  It finds its own built-ins in 
preference to finding external commands; so invoking "umask" (without 
directory name prefix) within a nosh script will always invoke the 
built-in chain-loading one, irrespective of PATH. (Several of the 
non-conformant shells do this, too, giving their built-ins unequivocal 
precedence over a PATH search.  Some even document this behaviour.  But 
it is not standard-conformant for a shell.)

* https://unix.stackexchange.com/a/496377/5132

* http://jdebp.uk./Softwares/nosh/guide/commands/exec.xml

execline always searches PATH.  It does not have built-ins like nosh or 
shells, in the first place.  There's a quirk about when changes to PATH 
take effect, and it does not quite have the POSIX semantics for when 
PATH is not set, but other than that it actually has the POSIX model 
behaviour: Commands are located using PATH, and what command one invokes 
by the name "umask" is entirely determined by what PATH lists.

* https://unix.stackexchange.com/a/448799/5132

Re: s6-log can create current with 640?

[Laurent Bercot]

>Not quite.  People find uses for these things, and as the SUS rationale points out, for every potentially useless external equivalent of a (non-special) built-in command someone has come up with an arcane actual use for it.  Even "cd".

Oh, definitely. And if my bathtub had a built-in trumpet, I could
certainly find a use for it, too; but that doesn't mean it would make
sense, no matter whether or not it's written in an official 
specification
for bathtubs.


>The POSIX model is therefore that all non-special built-ins are also available as executables; or, rather, that all of the standard utilities that are not special built-ins are simply *available* (via execvp(), find -exec, env, and *all of the other* ways that standard utilities can be invoked), and whether they are built-in or not, to a shell or otherwise, is an implementation detail as far as actually invoking the utility is concerned.

And I have no qualms about it for builtins that do something else than
just change the process state. But for a builtin that's supposed to only
change the process state, and whose use as an external program is
marginal at the very best, that model is terrible: it tries to make the
presence or absence of a shell undetectable (which it can never be), and
the consequences of that attempt leak outside of the legitimate domain
of the shell, and Dewayne's issue with umask is an illustration of this.

--
Laurent