[1003.1(2016)/Issue7+TC2 0001290]: arpa/inet.h - origin of socklen_t is unclear

[Austin Group Bug Tracker]

The following issue has been UPDATED. 
== 
http://austingroupbugs.net/view.php?id=1290 
== 
Reported By:joelsherrill
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1290
Category:   Base Definitions and Headers
Type:   Clarification Requested
Severity:   Editorial
Priority:   normal
Status: Interpretation Required
Name:   Joel Sherrill 
Organization:   RTEMS.org 
User Reference:  
Section:arpa/inet.h 
Page Number:NA - used web 
Line Number:NA - used web 
Interp Status:  Approved 
Final Accepted Text:See
http://austingroupbugs.net/view.php?id=1290#c4615 
== 
Date Submitted: 2019-09-27 19:20 UTC
Last Modified:  2020-01-14 16:23 UTC
== 
Summary:arpa/inet.h - origin of socklen_t is unclear
==
Relationships   ID  Summary
--
has duplicate   606  should be required ...
related to  0001289 netdb.h - in_port_t and in_addr_t do no...
== 

-- 
 (0004729) agadmin (administrator) - 2020-01-14 16:23
 http://austingroupbugs.net/view.php?id=1290#c4729 
-- 
Interpretation Approved: 14 Jan 2020 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2019-09-27 19:20 joelsherrill   New Issue
2019-09-27 19:20 joelsherrill   Name  => Joel Sherrill   
2019-09-27 19:20 joelsherrill   Organization  => RTEMS.org   
2019-09-27 19:20 joelsherrill   Section   => arpa/inet.h 
2019-09-27 19:20 joelsherrill   Page Number   => NA - used web   
2019-09-27 19:20 joelsherrill   Line Number   => NA - used web   
2019-10-07 15:39 eblake Relationship added   related to 0001289  
2019-10-07 15:46 nick   Note Added: 0004615  
2019-10-07 15:47 nick   Interp Status => Pending 
2019-10-07 15:47 nick   Final Accepted Text   => See
http://austingroupbugs.net/view.php?id=1290#c4615
2019-10-07 15:47 nick   Status   New => Interpretation
Required
2019-10-07 15:47 nick   Resolution   Open => Accepted As
Marked
2019-10-07 15:48 nick   Tag Attached: tc3-2008   
2019-12-12 17:32 agadminInterp StatusPending => Proposed 
2019-12-12 17:32 agadminNote Added: 0004685  
2019-12-18 18:59 denniswNote Added: 0004690  
2019-12-18 19:39 Don Cragun Relationship added   related to 606  
2019-12-19 16:12 geoffclare Relationship replacedhas duplicate 606
2020-01-14 16:23 agadminInterp StatusProposed => Approved
2020-01-14 16:23 agadminNote Added: 0004729  
==

RE: A question on file flags after fork

[Schwarz, Konrad]

> -Original Message-
> From: Ronald F. Guilmette 
> Sent: Tuesday, January 14, 2020 8:16 AM
> To: austin-group-l@opengroup.org
> Subject: Re: A question on file flags after fork
> 
> In message ,
> Shware Systems  wrote:
> 
> >Short answer, because both file descriptors reference the same file 
> >description...
> 
> OK.  I see where I took a wrong turn now, however I must say that I cannot 
> blame myself for having done so.  The
> language being used for the base concepts here is exceptionally stilted.  We 
> have -descriptors- and then we have
> file -descriptions-.  I get it now, but I cannot help but wish that the 
> original drafters, way back when, had
> elected to be a bit less clever and bit more obvious in their coinage of the 
> relevant terminology here.  The
> term "file desctriptor" was grandfathered in from the ancient times of UNIX.  
> So that was cast in stone and
> could not be reasonably changed.  But I would have been a LOT happier if 
> those standard drafters, back in the
> day, had elected to call what is apparently now called a "file description" 
> something else... a "purple
> aardvark" or basically anything other that the thing they finally settled on, 
> which is extraordinarily subject
> to misinterpretation, being as it is, so close to the term "file descriptor".

I imagine people were reluctant to use "file table entry", as that implied a 
certain implementation (a table).

> Moving ahead, now that my misreading has been corrected, I'd like to just 
> throw out a trial balloon and note
> that it would be pragmatically useful to provide some attributes that are 
> currently associated only with "file
> descriptions" also for file descriptors.  O_NONBLOCK is the one that is most 
> immediately apparent to me, but I
> can readily imagine usefulness also for permitting things like O_APPEND and 
> even O_RDONLY and O_WRONLY to be
> applied selectively to individual file descriptors, rather than to (shared) 
> file descriptions.  I will happily
> elaborate on a real-world scenario in which this would have been most useful 
> to have, if anyone is interested,
> and also the ugly ccode contortions that had to be applied in order to 
> work-around this particular non- feature,
> which I am now aware is 100% standard conformant.

The point of O_RDONLY and O_WRONLY being fixed is that file access permission 
checking is done only during the
open(); the resulting file descriptor can be passed on to executables with a 
different (lesser) set of permissions.
Similarly, with O_APPEND, you want to make sure that, e.g., earlier log entries 
cannot be destroyed by later ones
by processes outside of your control.

I agree that the case for O_NONBLOCK is less clear and was surprised that this 
is not stored as part
of the file descriptor (although the name does give it away).

Re: A question on file flags after fork

[Ronald F. Guilmette]

In message <16937.1578995...@jinx.noi.kre.to>, 
Robert Elz  wrote:

>But you do need some experience reading standards...

I would like to pause just longe enough to thank you all for the
unambiguously patronizing and derogatory manner in which you have
welcomed me into your community, all due apparently to my unforgivable
inability to instantly grasp the fine and semantically critical
distinction between the words "descriptor" and "description".

For the record, I served in the 1990s on both the C9X standardization
committee and also the original C++ standardization committee,  the
former with what I believe could be called distinction, since in that
instance I contributed a quite sizable number of both questions and
clarifications which were deemed of value to that effort.  Separately,
I was a major contributor to the standardization of DWARF syntax and
semantics which, if you have ever found yourselves debugging any
program in any compiled language on any modern *NIX system you have
most probably benefitted from.

I will be leaving you now, in peace.  My sincere apologies for having
disturbed your deliberations.  You have certainly succeeded in persuading
me that I am unworthy of even asking a question, at least not here,
but I shall most certainly be recommending this group and this mailing
list to any of my cohorts who feel themselves to be inadequately
demeaned by their spouses and/or immediate family members.


Regards,
rfg

RE: system() and pthread_atfork()

[Schwarz, Konrad]

> -Original Message-
> From: Robert Elz 
> Sent: Tuesday, January 14, 2020 11:35 AM
> To: Schwarz, Konrad (CT RDA IOT SES-DE) 
> Cc: nate.karst...@garmin.com; austin-group-l@opengroup.org
> Subject: Re: system() and pthread_atfork()


>   | The point I was trying to make with the text you did not quote is that
>   | if the OP had been more judicious in closing sockets/file descriptors,
>   | he would not have run into the problem in the first place.
> 
> The issue (as I understand it, I do not like the threading methedology, and 
> do not use it) is that in threaded
> processes, with everything happening in parallel, and no one thread having 
> any real idea what any other thread
> might be doing, there is no way to achieve the result you are expecting.
> 
> That is, at the exact same instant one thread is doing fork() another
> is doing open() or socket().   If it happens that the open() finishes one
> zeta-second before the fork() starts then the fd from that open will be 
> inherited by the child of the fork, but
> because the thread doing the open has not hat time to save the fd anywhere 
> yet, there is no way for the child
> process (which only contains the thread which forked, not the others, 
> including not the one that did the open())
> to ever discover what that fd was, or what it connects to.

But this is benign.  Only one thread is running in the new process,
that thread does not touch any sockets it knows nothing about,
and it will soon exec(), and the close-on-exit flag will do its job.

The mistake the OP was doing is to close the listening socket, which is bound 
to INADDR_ANY (and a fixed port),
in response to an IP address change.  When he does this and an unrelated fork() 
occurs,
a race ensures: if the exec() does not happen soon enough, the parent fails to 
rebind to the
socket, because it is still open in the child.

Had he simply left the existing listening socket alone, everything would have 
worked.

> 
>   | This seriously undermines the case for an all new F_CLOFORK flag
> 
> If it weren't for threading, I would not support it at all.   In any
> non-threaded context it is a stupid idea.   But I can see the need for
> it with our current threading methedology.   The real problem is that
> threads are a horrid misfeature.   Unfortunately, lots of people seem
> to like the evil things.

No use case demonstrating need for this feature has been presented up to now.

Re: system() and pthread_atfork()

[Robert Elz]

Date:Tue, 14 Jan 2020 08:35:14 +
From:"Schwarz, Konrad" 
Message-ID:  


  | Captain Obvious here:
  | A minimal quality of implementation attribute for DHCP daemons is for
  | these addresses to remain fixed for as long as possible.

Yes, address stability is useful, as connections break when it is
lost (given connections are identified by a tuple that includes the
address).

  | Cf. https://kb.isc.org/docs/isc-dhcp-44-manual-pages-dhcpdleases,
  | which is designed to persist address assignments across restarts,
  | e.g., because the hosting server needs to reboot.

It is a design goal.   Some dhcp servers have no stable storage at
all, and cannot meet that goal.

  | Or are you suggesting applications must be (re-)coded
  | such that they are resistant to dynamic changes of IP addresses?

There is no way around that.   Sometime addresses simply need to
change.  In the v4 world, the typical practice was to reconfigure
the system, and then reboot, which forced all the applications to
restart, with new addresses.  Not exactlty an ideal environment.

More recently, addresses can (even if they do not often) change
while the system is running, so yes, applications need to be able
to cope with that.

It is only because in practice the addresses do not change very
frequently - especially as most hosts live inside NAT enclaves,
where use of private addr space means there is very little incentive
to change, that there has been elatively little movement in this area.

But consider a mobile device (not mobile-IP here, just a typical
modern phone) that is using 4G comms as you move around, when you
with who knows what addr from your phone company, when you arrive
at my house, and connect to my WiFi, and are now using something
on network 10.*.*.* ... the addresses the apps on the phone are
seeing will have changed (unless the phone OS does a private internal
NAT, and makes some internal address space into whatever it is given
externally - which is just a method of coping with changing addresses,
not of avoiding it from happening).

eg: I know I need to, and so have a script to do it, restart
my sendmail daemon whenever my laptop connects to a different
access point, eg: when I move from my house to a hotspot provided
by my phone ... because sendmail doesn't deal with this well at all.

  | The point I was trying to make with the text you did not quote is that
  | if the OP had been more judicious in closing sockets/file descriptors,
  | he would not have run into the problem in the first place.

The issue (as I understand it, I do not like the threading methedology,
and do not use it) is that in threaded processes, with everything happening
in parallel, and no one thread having any real idea what any other
thread might be doing, there is no way to achieve the result you are
expecting.

That is, at the exact same instant one thread is doing fork() another
is doing open() or socket().   If it happens that the open() finishes one
zeta-second before the fork() starts then the fd from that open will
be inherited by the child of the fork, but because the thread doing the
open has not hat time to save the fd anywhere yet, there is no way for
the child process (which only contains the thread which forked, not the
others, including not the one that did the open()) to ever discover what
that fd was, or what it connects to.

  | This seriously undermines the case for an all new F_CLOFORK flag

If it weren't for threading, I would not support it at all.   In any
non-threaded context it is a stupid idea.   But I can see the need for
it with our current threading methedology.   The real problem is that
threads are a horrid misfeature.   Unfortunately, lots of people seem
to like the evil things.

kre

Re: A question on file flags after fork

[Robert Elz]

Date:Mon, 13 Jan 2020 23:16:03 -0800
From:"Ronald F. Guilmette" 
Message-ID:  <39544.1578986...@segfault.tristatelogic.com>

  | OK.  I see where I took a wrong turn now,

In which case the lengthy reply I just sent can be ignored...

  | however I must say that I
  | cannot blame myself for having done so.  The language being used for
  | the base concepts here is exceptionally stilted.

That is true, and is the nature of standards, and also legal documents.
They must be read particularly carefully, even the slightest variation
can mean something entirely different.   This is all in the nature of
aything where absolute precision is required.

  | But I would have been a LOT happier
  | if those standard drafters, back in the day, had elected to call what
  | is apparently now called a "file description" something else... a
  | "purple aardvark" or basically anything other that the thing they
  | finally settled on, which is extraordinarily subject to misinterpretation,
  | being as it is, so close to the term "file descriptor".

Perhaps, but that won't be the only thing like this that you find.

  | Moving ahead, now that my misreading has been corrected, I'd like to 
  | just throw out a trial balloon and note that it would be pragmatically
  | useful to provide some attributes that are currently associated only
  | with "file descriptions" also for file descriptors.

Not in both places, that would be a minefield.

  | O_NONBLOCK is the one that is most immediately apparent to me,

As I said in the previouys (long) reply, I think O_NONBLOCK was put
in the wrong place initially (though I suspect there were reasons).

  | but I can readily imagine
  | usefulness also for permitting things like O_APPEND

append mode is a less clear case, typically it wants to be shared.

  | and even O_RDONLY and O_WRONLY to be applied selectively to
  | individual file descriptors,

No, those cannot be, the permission checks are made only at open()
time, and after that the system assumes that if you have a file open
for read, then you have permission to read it (etc) - that's how a
setuid process can open a file, and then setuid(getuid()) to drop
its setuid status, and still continue to read the file, even though
it would not have permission to open the file for reading if it
attempted to open the file again now.

Those can only be set at open time, and consequently must apply to
everything that references the same file table entry ("file description").

Almost everything that can be traced back to the original unix design
has a very good reason for being exactly like it is.   Unfortunately,
non-blocking I/O is a more recent addition, and not all of those were
nearly as carefully thought out.

kre

Re: A question on file flags after fork

[Robert Elz]

Date:Mon, 13 Jan 2020 20:26:33 -0800
From:"Ronald F. Guilmette" 
Message-ID:  <38942.1578975...@segfault.tristatelogic.com>

  | While developing some C code recently, and testing that, I came upon a
  | VERY surprising and unexpected result.  It appears that various flavors
  | of *NIX are in agreement that after a fork, the set of flag bits (e.g.
  | O_NONBLOCK) that are associated with any specific file descriptor that
  | was open prior to the fork will, after the fork, exist only as a single
  | shared set of flag bits... *not* one copy for the parent and a separate
  | set for the child.

That is correct.

  | My reading of both the old and faded hardcopy of the 1993 POSIX API
  | standard that I have here, as well as the newer draft

If you can point at language in the current draft that suggested the
interpretation you have, and I agree it can be read the way you are
reading it, then I will file a defect report, as that would be incorrect.

Remember that the standard describes the way the implementations work
(which as you pointed out is the same for this issue, everywhere), it
does not legislate how they must behave (though to claim to conform one
must imlement what the standard reqires ... very few of the free OS versions.
if any, claim to conform howwver).But the standard should be able to
be used by people like you so you can correctly understand the way that
systems work (including the places where different implementations are
different - not that that is relevant here).  So if you are reasonably
interpreting the standard to say something it shouldn't, it should be
corrected.

But you do need some experience reading standards, they are not intended
as tutorials - and the language tends to be very precise, a slight difference
in wording, which in normal text would signify nothing at all, in a
standard can entirely change the meaning of what was said (which is similar
in a way to legal documents, like statutes, contracts, etc - the language is
very precisely defined.)

  | I have prepared two short example programs exclusively to illustrate the
  | issue.

There was no real need, we all know (and expect) the behaviour you mentioned.

But no, sorry, I do not have time to trawl through the standard looking
for where it says how things should work, but I will look at any text you
point out to me which you believe says something different.

(Give references to the 2018 draft, not the ancient 1993 version, much
has changed in that period.   You can reference section numbers, page
numbers, or line numbers (but also quote the text in question))

  | This occurs in both cases shortly after the recently forked child processes
  | have expressely and deliberately un-set the O_NONBLOCK flag for a file
  | descriptor that they have inherited a copy of at the time of the preceeding
  | fork.

That is what is supposed to happen.

  | How can diddling the flags for one file descriptor cause the flags of a
  | different file descriptor to magically change also?

Short (or not so short) answer, references to files in unix pass through
three levels of indirection.   This is ancient, from the earliest days.

At the bottom (close to the file) there is the inode (or vnode, or ...)
which is the actual description of a file, and contains all of the file's
data (the content of the file, and the meta-data like owner, access/modify
times (etc), permission bits, ...)   That one is identified by the combination
of an "inode number" and device (description of the filesyste, in which the
inode is housed).(File names are simply data in directories that map
human strings to inode numbers - the device for the inode is the same as
the device holding the directory  Names have files, files do not have
names).

Next up is the file table.   An entry in this is created for each open()
(and similar operations, like socket() etc) - the operations that create
a file descriptor from other data (a file name in the case of open()).
This is a single global shared table accessed by all of the processes
currently running.   There can be many file table entries referencing the
same file, for example
fd1 = open("file", ...);
fd2 = open("file", ...);
fd3 = open("file", ...);
will generate 3 different file table entries.   Each entry contains a
reference to the inode (all 3 of these would reference the same one),
plus the access mode (read/write/read-write) (one of the missing parameters
buried in the elipsis above) the current file offset, and almost all of
the mode flags relating to the file (all the ones that can be manipulated
using the fcntl(F_SETFL, ...) and fcntl(F_GETFL, ...) operations.  That
includes the non blocking mode.

Next up is the process file descriptor table.   This maps the small
integer file descrioptors (0, 1, 2, ...) that each process is given
from open() (etc) to references to the file table.   All the system
calls that manipulate file descriptors are manipu

Re: A question on file flags after fork

[Don Cragun]

Hi Danny and Ronald,
The austin-group-l e-mail list is a perfectly fine place to discuss the 
contents and interpretation of the current standard as well as the development 
of future revisions and amendments to the standard.  Places like 
unix.stackexchange.com and unix.com are fine places to go when you have 
questions about how to do something on BSD, Linux, and UNIX systems especially 
when discussing features that have not been standardized (jand frequently vary 
considerably in various versions of those operating systems, and, to a lesser 
degree even in various releases of a given version operating systems).

Any time you want an official interpretation of the standard, this is the place 
to come.

Hi Ronald,
The terms "file descriptor" and "file description" are both taken directly fro 
historic UNIX system documentation; neither was invented by developers of the 
standard.  Historic UNIX system man pages from 40 years ago seldom spelled out 
the relationship between those two terms as well of the current standard does.  
For example, the first two paragraphs of the DESCRIPTION section of the open() 
function man page (from page 1408, lines 46754-46762 in the 2017 edition of the 
standard):

The open() function shall establish the connection between
a file and a file descriptor. It shall create an open file
description that refers to a file and a file descriptor that
refers to that open file description. The file descriptor is
used by other I/O functions to refer to that file. The path
argument points to a pathname naming the file.

The open() function shall return a file descriptor for the
named file, allocated as described in Section 2.14 (on page
549). The open file description is new, and therefore the
file descriptor shall not share it with any other process in
the system. The FD_CLOEXEC file descriptor flag associated
with the new file descriptor shall be cleared unless the
O_CLOEXEC flag is set in oflag.

tries to clearly specify the relationship between the file descriptor and the 
file description that are created by a successful call to open().  Note also 
that the magic phrase "as described in" is almost always followed by a 
hyperlink in the PDF and in the HTML versions of the standard that you can 
click on to see that description.

We all realize that there are a lot of defined terms that you need to 
understand while reading the standard and that until you are used to the level 
of detail specified, it is easy to get confused.  When you use the standard 
frequently you get used to the terms used and learn where to find the 
definitions of those terms.  (Look especially at chapter 2 of the System 
Interfaces and Headers volume of the standard and at chapter 3 of the Base 
Definitions volume of the standard.  If you understand the concepts and 
definitions in those two places, many of your questions will have been 
answered.)

I hope this helps and look forward to seeing more of your questions in the 
future.

Sincerely,
Don Cragun
IEEE Portable Applications Standards Committee organizational representative to 
The Austin Group

> On Jan 13, 2020, at 11:25 PM, Ronald F. Guilmette  
> wrote:
> 
> In message , 
> Danny Niu wrote:
> 
>> Anyway, this mailing list should focus on **standard development**, 
>> questions like this of yours should go to places like unix.stackexchange.com.
> 
> I can only thank you for your kindness, grace, generosity, and understanding.
> I'm sure that these will all inspire others more worthy than myself to wish
> to contribute meaningfully to the ongoing standardization effort.
> 
> Regards,
> rfg
> 

RE: system() and pthread_atfork()

[Schwarz, Konrad]

> -Original Message-
> From: Robert Elz 
> Sent: Monday, January 13, 2020 1:43 PM
> To: Schwarz, Konrad (CT RDA IOT SES-DE) 
> Cc: nate.karst...@garmin.com; austin-group-l@opengroup.org
> Subject: Re: system() and pthread_atfork()
> 
> Date:Mon, 13 Jan 2020 10:13:04 +
> From:"Schwarz, Konrad" 
> Message-ID:  
> 
> 
>   | I actually feel this problem is out-of-scope for POSIX: compliant machines
>   | are not supposed to dynamically change their IP addresses at run-time.
> 
> I have no idea what (if anything) POSIX says about IP networking 
> requirements, but I'd expect not much, but that
> (if it were stated
> somewhere) would be an error.
> 
> [DHCP is allowed to dynamically change addresses]

Captain Obvious here:
A minimal quality of implementation attribute for DHCP daemons is for
these addresses to remain fixed for as long as possible.
Cf. https://kb.isc.org/docs/isc-dhcp-44-manual-pages-dhcpdleases,
which is designed to persist address assignments across restarts,
e.g., because the hosting server needs to reboot.

Or are you suggesting applications must be (re-)coded
such that they are resistant to dynamic changes of IP addresses?
 
> All that said, I agree that anything related to this issue would be out of 
> scope for POSIX, but the more general
> problem of threaded applications (which it must be, that's the only way that 
> the process can be simultaneously
> closing & opening sockets, while also, unknown to itself, also forking)
> and the interactions wrt fork & threads, is a POSIX issue.   That the
> actual problem is networking related is just a side issue, I believe.

The point I was trying to make with the text you did not quote is that
if the OP had been more judicious in closing sockets/file descriptors,
he would not have run into the problem in the first place.

This seriously undermines the case for an all new F_CLOFORK flag and associated
paraphernalia.  Indeed, except for Solaris, no implementation has ever
implemented this, presumably because there is no real-world need for it.


smime.p7s
Description: S/MIME cryptographic signature