Re: CVS commit: src/bin/sh

2016-01-04 Thread Taylor R Campbell 
   Date: Mon, 4 Jan 2016 20:06:55 -0500
   From: chris...@zoulas.com (Christos Zoulas)

   On Jan 5,  5:33am, k...@munnari.oz.au (Robert Elz) wrote:
   -- Subject: Re: CVS commit: src/bin/sh

   |   | Does the exec'ed program know what to do with fd > 2?
   |   | Is it hard-coded, or do we specify it with -fd N?
   | 
   | More likely, if this ever was to be used, it would be /dev/fd/N
   | but certainly this is not going to be common.

   Right, otherwise people would complain a lot more about ksh than
   they currently do looking at the web...

I'm pretty sure I have shell scripts that rely on /dev/fd/N working as
an exec'd command argument for N > 2.  An example of an exec'd program
that uses N > 2 without /dev/fd/N is gpg, with the --passphrase-fd,
--command-fd, --status-fd options.  I would be unhappy if these broke.

...unless I've misunderstood what this thread is about from my very
cursory skimming of it.

Re: CVS commit: src/bin/sh

2016-01-04 Thread Christos Zoulas 
On Jan 5,  5:33am, k...@munnari.oz.au (Robert Elz) wrote:
-- Subject: Re: CVS commit: src/bin/sh

| The exec'd programs in my case however tend to be #!/bin/sh scripts
| that are tightly coupled to the script calling them.

Ok, this I think will break.

|   | Does the exec'ed program know what to do with fd > 2?
|   | Is it hard-coded, or do we specify it with -fd N?
| 
| More likely, if this ever was to be used, it would be /dev/fd/N
| but certainly this is not going to be common.

Right, otherwise people would complain a lot more about ksh than
they currently do looking at the web...

| Obviously it would not need to be ! ... N>&&M or N>&:M or something
| that doesn't have a meaning (a sh syntax char would be better than
| a "word" char like : though).

Something like it... Still I think I will start a discussion in the
very infrequently used bourne shell mailing list...

|   | I am leaning towards the fcntl builtin solution...
| 
| So was I when I finished writing it.  Still am.

Heh.

|   | Perhaps, if we could do that and re-open with append.
| 
| Re-open what?   I'm just suggesting a specific (explicit) close in the
| exact same place that a close on exec would happen.   What the shell
| does internally if the cmd exec fails we cannot do anything about (or
| rely upon), all that matters is the state left behind after, and in that
| the fd is still open - the close only affects "command".

exec 7>&- 8>&-
command
# reopen 7 and 8 and point them to what they were before.

Now the shell output when it fails to execute command, will not go
to 7 and 8 as it was expected.

| Ah, even though I looked for it, I missed the "to > 2" part.   Now I
| just want to see how this gets documented in a way that makes it
| seem other than foolish.

I would say something:

Shell file-descriptor redirections are marked close-on-exec unless the
descriptors they point to refer to the standard input, output, or error.

| Incidentally, the other case, where you call " copyfd(f, fd, 1, fd > 2); "
| the "fd > 2" bit is really redundant, the code inside copyfd (as it exists)
| ends up causing a test that amounts to
| 
|   if (fd > 2 && fd > 2)
| 
| which is kind of redundant.   That "fd > 2" might just as well be "1"
| like in the other calls.

Totally redundant.

| I guess I am going to have to set up a current system and try some of
| my scripts that do this kind of thing on it, and see what happens.
| I suspect this kind of sh usage is exotic enough that comparatively few
| people ever use it.

Please do.

| Anyway, enough for now, others probably should be giving opinions
| on how they think all this really should work.

I was waiting for that but I am getting radio silence.

christos

Re: CVS commit: src/bin/sh

2016-01-04 Thread Robert Elz 
Date:Mon, 4 Jan 2016 16:50:18 -0500
From:chris...@zoulas.com (Christos Zoulas)
Message-ID:  <20160104215018.4017617f...@rebar.astron.com>


  | Sure, I think that there are examples where the parent/child shells use
  | fds > 2 to communicate, but with an exec'ed program?

Sure, if you're thinking some random NetBSD binary from /bin or /usr/pkg/bin
then probably not.

The exec'd programs in my case however tend to be #!/bin/sh scripts
that are tightly coupled to the script calling them.

  | Does the exec'ed program know what to do with fd > 2?
  | Is it hard-coded, or do we specify it with -fd N?

More likely, if this ever was to be used, it would be /dev/fd/N
but certainly this is not going to be common.

  | Well, ! means overwrite in re-directions...

Obviously it would not need to be ! ... N>&&M or N>&:M or something
that doesn't have a meaning (a sh syntax char would be better than
a "word" char like : though).

  | I am leaning towards the fcntl builtin solution...

So was I when I finished writing it.  Still am.

  | Perhaps, if we could do that and re-open with append.

Re-open what?   I'm just suggesting a specific (explicit) close in the
exact same place that a close on exec would happen.   What the shell
does internally if the cmd exec fails we cannot do anything about (or
rely upon), all that matters is the state left behind after, and in that
the fd is still open - the close only affects "command".

  | These two are identical since 0, 1, 2 fd's are never touched.

Ah, even though I looked for it, I missed the "to > 2" part.   Now I
just want to see how this gets documented in a way that makes it
seem other than foolish.

Incidentally, the other case, where you call " copyfd(f, fd, 1, fd > 2); "
the "fd > 2" bit is really redundant, the code inside copyfd (as it exists)
ends up causing a test that amounts to

if (fd > 2 && fd > 2)

which is kind of redundant.   That "fd > 2" might just as well be "1"
like in the other calls.

I guess I am going to have to set up a current system and try some of
my scripts that do this kind of thing on it, and see what happens.
I suspect this kind of sh usage is exotic enough that comparatively few
people ever use it.

Anyway, enough for now, others probably should be giving opinions
on how they think all this really should work.

kre

Re: CVS commit: src/bin/sh

2016-01-04 Thread Christos Zoulas 
On Jan 5,  4:40am, k...@munnari.oz.au (Robert Elz) wrote:
-- Subject: Re: CVS commit: src/bin/sh

|   | - Is leaving descriptors open really needed? I can write the above
|   |   example in a way it works...
| 
| That one yes, but there are cases where more than one open doesn't work.

Sure, I think that there are examples where the parent/child shells use
fds > 2 to communicate, but with an exec'ed program? Does the exec'ed program
know what to do with fd > 2? Is it hard-coded, or do we specify it with -fd N?
It does not look like this is the common case.

| 
|   | - Should portable code rely on open file descriptors across exec, 
since
|   |   it is unspecified behavior?
| 
| No, portable code shouldn't, but sometimes we (or at least I) just need
| code that works for me, with no intent that it ever be used elsewhere
| (and often where no-one else would even conceivably be interested).

The knob would help for that.

| If the build system, and the rc scripts, all work with your modified sh, then
| clearly they aren't depending upon that behaviour, and in that case,
| fixing them to explicitly close the "save for later" fds should not be
| difficult (painstaking to actually do perhaps, but not difficult.)

They seem to work fine.

|   | - Should there be away to control this from the shell? And if there
|   |   is what should the default be? What should the syntax be?
| 
| Control, yes, probably.  The default should be the way NetBSD has
| always been.  It isn't a bug, and of itself it isn't a security issue
| (though, as always, sloppy code can make security holes), so we should
| retain compat with what we have always had, at least as the default case.
| 
| Syntax ... no answers right now, a different > operator perhaps (7>&!3 ?)
| (would be easiest to convert existing code if it prefers the other way),
| or a new built in command to set/reset close on exec on a (set of) fd
| (which could also manipulate other fd flags for the shell as well,
| not that most of the others would be useful - we could even call it "fcntl")

Well, ! means overwrite in re-directions... I am leaning towards the fcntl
builtin solution...

|   |   - Setup redirections so that stdout and stderr are captured
|   |   - Execute command, where if successful the file descriptors
|   | are closed, and if it failed, they are kept open for further
|   | processing.
| 
| command fd>&- ...
| 
| The cmd is run (if it can be) with fd closed.   In the shell, fd remains
| open (to be closed later, either explicitly, or upon exit) and if needed
| you can do whatever afterwards, including closing fd (or moving it back to
| stdout) if the workaround is no longer needed.
| 
| Obviously the "command" the redirect is added to needs to be the one
| (or parent of the set) where fd is not needed, not just another of the
| set of rc scripts/functions.

Perhaps, if we could do that and re-open with append. I am not sure
what happens with concurrency though.

| 
|   | Yup, it works. Nothing would work if it did not.
| 
| Really?   How frequently do we do "exec >file" in anything that
| is actually used (if the explicit number makes a difference, write
| it as "exec 1>file" - those two should be identical).

These two are identical since 0, 1, 2 fd's are never touched. OTOH
exec 6> foo isn't.

|   | The closeon-exec feature is only for specific redirections 
|   | (redirections to specific file numbers).
| 
| Yes, understood, but that's what I asked about, when the specific
| file number is 1 (or 0 or 2) - I saw nothing in the code that would
| prevent close-on-exec being set for them.

The check is in both copyfd() and in the specific fcntl case.

| I just did your test (as below) again using ksh (NetBSD's /bin/ksh, not
| the real one) and sure enough, it fails, when using fd 6.   But if I change
| it to use "1" instead of "6", then it works, so clearly ksh is doing
| different things depending upon what the fd value happens to be.   I have
| no idea how they explain that.
| 
|   | I.e. should I expect the following to work?
|   | 
|   | $ cat test1
|   | #!/bin/sh
|   | exec 6> out
|   | echo "test" >&6
|   | sh ./test2
|   | exec 6>&-
|   | 
|   | $ cat test2
|   | cat cloexec/test2
|   | echo "test2" >&6
|   | 
|   | $ ./test1
| 
| Aside from the "cat cloexec/test2" line, which I suspect might be a pasto
| in construction of your mail, otherwise I have no idea what that's about,
| then yes, on NetBSD it should work, and should write
|   test
|   test2
| to the file "out".   That's what it does on my system (which does not have
| your changed shell) right now.   Unless there is a very good reason, that
| is what it should continue to do.
| 
| Whether anyone should write code like that, which depends upon it working
| that way is a different question, to which the answer is probably, "no",
| but sometimes doing it differently is hard - harder than justified by the
| requirements.
| 
| The place I use exec redirecti

Re: CVS commit: src/bin/sh

2016-01-04 Thread Robert Elz 
Date:Mon, 4 Jan 2016 14:41:30 -0500
From:chris...@zoulas.com (Christos Zoulas)
Message-ID:  <20160104194130.6064f17f...@rebar.astron.com>


  | Yes, the issues are:
  | 
  | - Is leaving descriptors open really needed? I can write the above
  |   example in a way it works...

That one yes, but there are cases where more than one open doesn't work.

  | - Should portable code rely on open file descriptors across exec, since
  |   it is unspecified behavior?

No, portable code shouldn't, but sometimes we (or at least I) just need
code that works for me, with no intent that it ever be used elsewhere
(and often where no-one else would even conceivably be interested).

If the build system, and the rc scripts, all work with your modified sh, then
clearly they aren't depending upon that behaviour, and in that case,
fixing them to explicitly close the "save for later" fds should not be
difficult (painstaking to actually do perhaps, but not difficult.)

  | - Should there be away to control this from the shell? And if there
  |   is what should the default be? What should the syntax be?

Control, yes, probably.  The default should be the way NetBSD has
always been.  It isn't a bug, and of itself it isn't a security issue
(though, as always, sloppy code can make security holes), so we should
retain compat with what we have always had, at least as the default case.

Syntax ... no answers right now, a different > operator perhaps (7>&!3 ?)
(would be easiest to convert existing code if it prefers the other way),
or a new built in command to set/reset close on exec on a (set of) fd
(which could also manipulate other fd flags for the shell as well,
not that most of the others would be useful - we could even call it "fcntl")

  | - Setup redirections so that stdout and stderr are captured
  | - Execute command, where if successful the file descriptors
  |   are closed, and if it failed, they are kept open for further
  |   processing.

command fd>&- ...

The cmd is run (if it can be) with fd closed.   In the shell, fd remains
open (to be closed later, either explicitly, or upon exit) and if needed
you can do whatever afterwards, including closing fd (or moving it back to
stdout) if the workaround is no longer needed.

Obviously the "command" the redirect is added to needs to be the one
(or parent of the set) where fd is not needed, not just another of the
set of rc scripts/functions.


  | Yup, it works. Nothing would work if it did not.

Really?   How frequently do we do "exec >file" in anything that
is actually used (if the explicit number makes a difference, write
it as "exec 1>file" - those two should be identical).

  | The closeon-exec feature is only for specific redirections 
  | (redirections to specific file numbers).

Yes, understood, but that's what I asked about, when the specific
file number is 1 (or 0 or 2) - I saw nothing in the code that would
prevent close-on-exec being set for them.

I just did your test (as below) again using ksh (NetBSD's /bin/ksh, not
the real one) and sure enough, it fails, when using fd 6.   But if I change
it to use "1" instead of "6", then it works, so clearly ksh is doing
different things depending upon what the fd value happens to be.   I have
no idea how they explain that.

  | I.e. should I expect the following to work?
  | 
  | $ cat test1
  | #!/bin/sh
  | exec 6> out
  | echo "test" >&6
  | sh ./test2
  | exec 6>&-
  | 
  | $ cat test2
  | cat cloexec/test2
  | echo "test2" >&6
  | 
  | $ ./test1

Aside from the "cat cloexec/test2" line, which I suspect might be a pasto
in construction of your mail, otherwise I have no idea what that's about,
then yes, on NetBSD it should work, and should write
test
test2
to the file "out".   That's what it does on my system (which does not have
your changed shell) right now.   Unless there is a very good reason, that
is what it should continue to do.

Whether anyone should write code like that, which depends upon it working
that way is a different question, to which the answer is probably, "no",
but sometimes doing it differently is hard - harder than justified by the
requirements.

The place I use exec redirections most is when I really want to write

while read a b c
do
commands
done < file

which is fine, except when I need the result of "commands" to affect
the state of the shell outside the loop (like variable assignments).
There are some gross hacks that can be used to deal with that, but the
most elegant is to convert it to ...

exec 9<&0
exec 0

Re: CVS commit: src/bin/sh

2016-01-04 Thread Christos Zoulas 
On Jan 5,  2:07am, k...@munnari.oz.au (Robert Elz) wrote:
-- Subject: Re: CVS commit: src/bin/sh

| It isn't a matter of whether it can be made to work or not for
| NetBSD's build system, or whether you have hodden a bug in the
| rc scripts (I'll explain why "hidden" rather than "fixed" below)
| but of what is right.
| 
| In the test case you included in the commit log, I expect the
| echo in test2 to work, and write to file "out" the way NetBSD's
| sh (and all Bourne shell variants, since the first one) have
| always done.
| 
| That is, the shell code
| 
|   exec 3>&1
|   cmd
| 
| is (and always was intended to be) the same as the (abbreviated) C code
| 
|   dup2(1, 3);
|   if (fork() == 0)
|   execlp("cmd", "cmd", (char *)0);
|   else
|   wait(&status);
| 
| The case you use "exec 6>out" is similar, but messier to write directly
| in C because there's no "open_giving_fd_n()" function, so it needs an
| open/dup2/close sequence, so I'll omit that one (I'd probably
| get it wrong...).  The effect should be the same however.
| 
| If I wanted fd 6 closed when test2 was run in your example, I'd write
| the line that runs it as ...
| 
|   sh ./test2 6>&-
| 
| We know fd 6 is open at that point, the "exec >&6" is there explicitly,
| and the close hasn't happened yet.
| 
| Now I know that POSIX says you're allowed to do it the way you have changed
| it to, but that's only because ksh (for whatever reason) decided to change
| the semantics, and what ksh does seems to have inordinate sway with the
| posix shell people...
| 
| But, they say ...
| 
|   it is unspecified whether those file descriptors remain open
|   when the shell invokes another utility
| 
| so the way that NetBSD's shell (and Bourne shells in general) have always
| done it is just as valid.

Yes, the issues are:

- Is leaving descriptors open really needed? I can write the above
  example in a way it works...
- Should portable code rely on open file descriptors across exec, since
  it is unspecified behavior?
- Should there be away to control this from the shell? And if there
  is what should the default be? What should the syntax be?

| That's why you haven't "fixed" anything in the rc system by the change.
| What you have done is made it rely upon (your version of) NetBSD's
| implementation of that unspecified operation.   Take the scripts to any
| other (rational) system and the bug (if there is one) would reappear.
| On NetBSD the bug will be hidden, which makes it one of more insidious type.

Yes, but fixing this is not easy I think, without relying on a non-portable
feature of the shell to do it (or forking another subshell). What we want is:

- Setup redirections so that stdout and stderr are captured
- Execute command, where if successful the file descriptors
  are closed, and if it failed, they are kept open for further
  processing.

| If there is a bug there, it should be fixed in the scripts (by explicitly
| closing fd's that have been opened using exec when they are not needed).

If possible yes, we should definitely fix them.

| The "if" is not because I believe the daemons you showed need, or want,
| to have those fds open, but because the rc scripts are complex, and I
| have not analysed them to determine whether they are relying upon the
| "keep open through exec" behaviour for some reason.  And yes, that would
| also be relying on unspecified behaviour, but it is at least the ancient
| historic behaviour, where it is very hard to code correctly in any sane way
| if close_on_exec is forced on when it is not wanted (whereas it is trivial
| to close fds that have been opened but are not wanted).

Yes, I think that the scripts could be fixed by doubling the amount of forking..
I could be wrong though.

| kre
| 
| ps: have you tested the shell with your change to make sure that
| 
|   exec >outfile
| 
| followed by
| 
|   cmd1; cmd2; cmd3
| 
| doesn't run those commands with stdout closed?

Yup, it works. Nothing would work if it did not. The closeon-exec feature
is only for specific redirections (redirections to specific file numbers).
I.e. should I expect the following to work?

$ cat test1
#!/bin/sh
exec 6> out
echo "test" >&6
sh ./test2
exec 6>&-

$ cat test2
cat cloexec/test2
echo "test2" >&6

$ ./test1

I am open to suggestions, but I think that closing on exec is a nice
feature to have from the security POV, and it should be the default,
unless otherwise specified. I view the ksh behavior a correction
to the loose standard that was just there before close on exec did not
even exist when the shell file-descriptor redirection was invented IIRC.

christos

Re: CVS commit: src/bin/sh

2016-01-04 Thread Robert Elz 
Date:Mon, 4 Jan 2016 08:26:29 -0500
From:chris...@zoulas.com (Christos Zoulas)
Message-ID:  <20160104132629.a6ee017f...@rebar.astron.com>

  | Ksh does it and it works... I must have been too aggressive.

It isn't a matter of whether it can be made to work or not for
NetBSD's build system, or whether you have hodden a bug in the
rc scripts (I'll explain why "hidden" rather than "fixed" below)
but of what is right.

In the test case you included in the commit log, I expect the
echo in test2 to work, and write to file "out" the way NetBSD's
sh (and all Bourne shell variants, since the first one) have
always done.

That is, the shell code

exec 3>&1
cmd

is (and always was intended to be) the same as the (abbreviated) C code

dup2(1, 3);
if (fork() == 0)
execlp("cmd", "cmd", (char *)0);
else
wait(&status);

The case you use "exec 6>out" is similar, but messier to write directly
in C because there's no "open_giving_fd_n()" function, so it needs an
open/dup2/close sequence, so I'll omit that one (I'd probably
get it wrong...).  The effect should be the same however.

If I wanted fd 6 closed when test2 was run in your example, I'd write
the line that runs it as ...

sh ./test2 6>&-

We know fd 6 is open at that point, the "exec >&6" is there explicitly,
and the close hasn't happened yet.

Now I know that POSIX says you're allowed to do it the way you have changed
it to, but that's only because ksh (for whatever reason) decided to change
the semantics, and what ksh does seems to have inordinate sway with the
posix shell people...

But, they say ...

it is unspecified whether those file descriptors remain open
when the shell invokes another utility

so the way that NetBSD's shell (and Bourne shells in general) have always
done it is just as valid.

That's why you haven't "fixed" anything in the rc system by the change.
What you have done is made it rely upon (your version of) NetBSD's
implementation of that unspecified operation.   Take the scripts to any
other (rational) system and the bug (if there is one) would reappear.
On NetBSD the bug will be hidden, which makes it one of more insidious type.

If there is a bug there, it should be fixed in the scripts (by explicitly
closing fd's that have been opened using exec when they are not needed).

The "if" is not because I believe the daemons you showed need, or want,
to have those fds open, but because the rc scripts are complex, and I
have not analysed them to determine whether they are relying upon the
"keep open through exec" behaviour for some reason.  And yes, that would
also be relying on unspecified behaviour, but it is at least the ancient
historic behaviour, where it is very hard to code correctly in any sane way
if close_on_exec is forced on when it is not wanted (whereas it is trivial
to close fds that have been opened but are not wanted).

kre

ps: have you tested the shell with your change to make sure that

exec >outfile

followed by

cmd1; cmd2; cmd3

doesn't run those commands with stdout closed?

Re: CVS commit: src/libexec/httpd

2016-01-04 Thread Marc Balmer 

> Am 03.01.2016 um 23:23 schrieb Kamil Rytarowski :
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> It's a good tip.
> 
> I would leave httpd.print as it is right now, to not make a false
> impression that there standard print works. The standard one will
> work, but not for HTTPS.

Oh, I was not suggesting you change the file again, I jsut wanted to note that 
a single line change would have been enough ;)

> 
> On 03.01.2016 11:15, Marc Balmer wrote:
>> Just a note: A better change would have been to just add
>> 
>> print = httpd.print
>> 
>> at the start of the script.  That way the script could still be 
>> used as a normal CGI script with minimal changes.
>> 
>> 
>>> Am 07.12.2015 um 04:11 schrieb Kamil Rytarowski 
>>> :
>>> 
>>> Module Name:src Committed By:   kamil Date: Mon Dec 
>>>  7 03:11:48 
>>> UTC 2015
>>> 
>>> Modified Files: src/libexec/httpd: printenv.lua
>>> 
>>> Log Message: Improve the httpd(8) printenv.lua Lua example
>>> 
>>> Stop using Lua builtin print function and replace them with 
>>> http.* ones. httpd.print and http.write wraps SSL support when 
>>> needed.
>>> 
>>> Print http headers, without them browser may interpret page as 
>>> raw text.
>>> 
>>> No need to hardcode prefix path in the form.
>>> 
>>> Add comments for a user with tips how to use this script.
>>> 
>>> Patch by Travis Paul
>>> 
>>> Closes PR misc/50502
>>> 
>>> 
>>> To generate a diff of this commit: cvs rdiff -u -r1.2 -r1.3 
>>> src/libexec/httpd/printenv.lua
>>> 
>>> Please note that diffs are not public domain; they are subject
>>> to the copyright notices on the relevant files.
>>> 
>>> Modified files:
>>> 
>>> Index: src/libexec/httpd/printenv.lua diff -u 
>>> src/libexec/httpd/printenv.lua:1.2 
>>> src/libexec/httpd/printenv.lua:1.3 --- 
>>> src/libexec/httpd/printenv.lua:1.2  Thu Jan  2 08:21:38 2014 +++ 
>>> src/libexec/httpd/printenv.lua  Mon Dec  7 03:11:48 2015 @@ -1,4 
>>> +1,4 @@ --- $NetBSD: printenv.lua,v 1.2 2014/01/02 08:21:38 mrg 
>>> Exp $ +-- $NetBSD: printenv.lua,v 1.3 2015/12/07 03:11:48 kamil 
>>> Exp $
>>> 
>>> -- this small Lua script demonstrates the use of Lua in 
>>> (bozo)httpd -- it will simply output the "environment" @@ -8,6 
>>> +8,10 @@ -- the same value on each invocation.  You can not keep 
>>> state between -- two calls.
>>> 
>>> +-- You can test this example by running the following command: 
>>> +-- /usr/libexec/httpd -b -f -I 8080 -L test printenv.lua . +-- 
>>> and then navigate to: http://127.0.0.1:8080/test/printenv +
>>> local httpd = require 'httpd'
>>> 
>>> function printenv(env, headers, query) @@ -15,12 +19,14 @@ 
>>> function printenv(env, headers, query) -- we get the 
>>> "environment" in the env table, the values are more -- or less 
>>> the same as the variable for a CGI program
>>> 
>>> -   if count == nil then -  count = 1 - end - - -- output a 
>>> header
>>> -   print([[ +  -- output headers using httpd.write() + -- 
>>> httpd.write() will not append newlines +httpd.write("HTTP/1.1 
>>> 200 Ok\r\n") +  httpd.write("Content-Type: text/html\r\n\r\n") +
>>> + -- output html using httpd.print() +  -- you can also use
>>> print() and io.write() but they will not work with SSL +
>>> httpd.print([[   Bozotic Lua
>>> Environment @@ -29,54 +35,58 @@ function printenv(env,
>>> headers, query) Bozotic Lua Environment ]])
>>> 
>>> -   print('module version: ' .. httpd._VERSION .. '') + 
>>> httpd.print('module version: ' .. httpd._VERSION .. '')
>>> 
>>> -   print('Server Environment') +  httpd.print('Server 
>>> Environment') -- print the list of "environment" variables 
>>> for k, v in pairs(env) do - print(k .. '=' .. v .. '') + 
>>> httpd.print(k .. '=' .. v .. '') end
>>> 
>>> -   print('Request Headers') + httpd.print('Request 
>>> Headers') for k, v in pairs(headers) do -  print(k .. '='
>>> .. v .. '') +  httpd.print(k .. '=' .. v .. '') end
>>> 
>>> if query ~= nil then -  print('Query Variables') + 
>>> httpd.print('Query Variables') for k, v in pairs(query) 
>>> do -print(k .. '=' .. v .. '') +   
>>> httpd.print(k .. '=' 
>>> .. v .. '') end end
>>> 
>>> -   print('Form Test') +   httpd.print('Form 
>>> Test')
>>> 
>>> -   print([[ -  
>>> + httpd.print([[ +   
>>>   
>>> ]]) -- output a footer -print([[ +  httpd.print([[  
>>>  ]]) end
>>> 
>>> function form(env, header, query) + +   httpd.write("HTTP/1.1 200 
>>> Ok\r\n") +  httpd.write("Content-Type: text/html\r\n\r\n") + if 
>>> query ~= nil then - print('Form Variables') + 
>>> httpd.print('Form Variables')
>>> 
>>> if env.CONTENT_TYPE ~= nil then -   print('Content-type: ' 
>>> .. 
>>> env.CONTENT_TYPE .. '') +   
>>> httpd.print('Content-type: ' .. 
>>> env.CONTENT_TYPE .. '') end
>>> 
>>> for k, v in pairs(query) do -   print(k .. '=' .. v .. 
>>> '')
>>> + httpd.

Re: CVS commit: src/bin/sh

2016-01-04 Thread Christos Zoulas 
On Jan 4,  5:56pm, k...@munnari.oz.au (Robert Elz) wrote:
-- Subject: Re: CVS commit: src/bin/sh

| I think this is incorrect.   Standard practice has always been that
| any open fds in the parent are passed on to the child at fork(), and
| remain open through exec() unless they have close-on-exec set (for which
| there is no shell syntax, though perhaps there should be).

Ksh does it and it works... I must have been too aggressive. I will back
it out and retry. I'll back it out for now if someone else has not already.

christos

Re: CVS commit: src/bin/sh

2016-01-04 Thread Robert Elz 
Date:Sun, 3 Jan 2016 22:00:24 -0500
From:"Christos Zoulas" 
Message-ID:  <20160104030024.30647f...@cvs.netbsd.org>

  | Don't leak redirected rescriptors to exec'ed processes.

I think this is incorrect.   Standard practice has always been that
any open fds in the parent are passed on to the child at fork(), and
remain open through exec() unless they have close-on-exec set (for which
there is no shell syntax, though perhaps there should be).

  | This fixes by side effect the problem of the rc system leaking file
  | descriptors 7 and 8 to all starting daemons:

If that's actually a leak in the rc system (rather than by design because
some sub-shells need the fds - in which case you just broke it) then fixing
it in the scripts would be easy.

It appears from a later message from martin@ that this change has also
broken the build system.

Reverting it would be a very good idea.

kre

Re: CVS commit: src/sys/arch/i386/stand/bootxx

2016-01-04 Thread Martin Husemann 
On Mon, Jan 04, 2016 at 06:33:50PM +1100, matthew green wrote:
> "Christos Zoulas" writes:
> > Module Name:src
> > Committed By:   christos
> > Date:   Sun Jan  3 20:59:47 UTC 2016
> > 
> > Modified Files:
> > src/sys/arch/i386/stand/bootxx: pbr.S
> > 
> > Log Message:
> > change 60 to 70 which is the current release. Noticed by Rares Aioanei.
> 
> i don't think so we should do this unless we change the protocol,
> as jak mentioned.  this can be intepreted by the BIOS and it might
> do differnet stuff so unless there's actually a good reason for it
> this change could break something that works (poorly.)

If changing it at all, we should just remove the version info and use
"NetBSD  " or similar.

Grep for "NETBSD60" in qemu, other virtual emulators binaries and grub
sources is probably good enough to check for real world things that could
care.

Martin