mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Markus Wichmann <nullplan@gmx.net>
To: musl@lists.openwall.com
Subject: Re: <shadow.h> function: fgetspent_r
Date: Fri, 18 Jan 2019 21:37:25 +0100	[thread overview]
Message-ID: <20190118203725.GI29911@voyager> (raw)
In-Reply-To: <20190117153830.GN23599@brightrain.aerifal.cx>

Hi all,

so I had a look at the glibc implementation (from v2.24, which I had
lying around), and here are my findings: They don't return on format
error. Instead, they loop.

On buffer too short, they will leave the stream where it is and return
ERANGE. And on end of file, they return ENOENT, which I find bizarre.

Looking at my own implementation, I am not certain if cleaning up a
faulty state is desirable, since non-recoverable situations exist.
fgetspent_r() has the invariant that the file position is pointing to
the start of a line. So, first thought was to use ftell() beforehand and
fseek() on error, to revert to the start of a line. However, that really
only helps with the "buffer too short" case. An illegal line won't
become more acceptable, no matter how many times we reread it.

Rich correctly pointed out that a file might not be seekable. So if
reversing isn't an option, we can only go forward. So I added an fgets()
loop in case the fseek() fails. But fgets() can fail, too. Maybe even
spuriously (what happens if the file is actually an fdopen()ed
nonblocking TCP socket or something?), so that the problem fixes itself.
Then the invariant is still violated and we have no indication of
anything being wrong.

So, since it is impossible to guarantee the invariant, and the user
certainly has no way to check, I think telling the user to close the
file on any error is probably the best choice here (i.e. the choice that
saves me the most work).

Looping on format error sounds attractive as well, but I think we'd want
that behavior to be consistent across the entire src/passwd directory,
right? It would allow slightly broken files to be present in the system
without bricking it. On the other hand, permissivity is usually only a
good thing outside of security contexts.

Thoughts?

Ciao,
Markus


  reply	other threads:[~2019-01-18 20:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-16 19:21 A. Wilcox
2019-01-16 20:50 ` Rich Felker
2019-01-16 21:38   ` A. Wilcox
2019-01-16 23:44     ` Rich Felker
2019-01-17  5:31       ` Markus Wichmann
2019-01-17 15:38         ` Rich Felker
2019-01-18 20:37           ` Markus Wichmann [this message]
2019-01-20 15:41             ` Markus Wichmann
2019-01-20 21:12               ` A. Wilcox
2019-01-21  0:50                 ` Rich Felker
2019-01-20 22:02               ` A. Wilcox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190118203725.GI29911@voyager \
    --to=nullplan@gmx.net \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

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