bug-texinfo
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: install-info can "corrupt" dir file if interrupted.


From: Gavin Smith
Subject: Re: install-info can "corrupt" dir file if interrupted.
Date: Sat, 3 Dec 2022 15:25:20 +0000

Link to archived discussion:

https://lists.gnu.org/archive/html/bug-texinfo/2015-11/msg00031.html

On Fri, Nov 20, 2015 at 02:23:36PM -0800, Pedrum Mohageri wrote:
> > Can you point to an explanation or example of how to update a file
> > without the risk of truncation? It would seem that there's the risk of
> > this happening any time that fopen (... , "w") is used; should that be
> > considered a bad way to update a file.
> >
> >
> You can use the standard practice of 1) writing to temp file 2) renaming
> temp file to final file. This ensures the file contents are fully on disk
> before the name change occurs.
> 
> See also:
> http://www.gnu.org/software/libc/manual/html_node/Temporary-Files.html.
> 
> There are various libc ways to get a tempfile securely, and then use a
> rename/linkat calls to rename to filename you're replacing.
> 
> 
> > > While this is rare occurrence, I've seen numerous failures like this
> > reported
> > > on Redhat and Arch forums.
> >
> > Can you email links to these reports?
> >
> >
> https://bugzilla.redhat.com/show_bug.cgi?id=581995
> https://bbs.archlinux.org/viewtopic.php?pid=673587

The report was dir file corruption if install-info was interrupted.

I've attempted to fix this issue by creating a temporary file with
mkstemp, and then renaming it.  I've added the Gnulib module for mkstemp
as it will not exist on MS-Windows.

I would not be surprised if this leads to more problems.  The documentation
on temporary files is somewhat bewildering and I could have implemented
this easily with functions like tmpnam that various sources tell you not
to use.

I doubt that the security problems are real problems in our case, although
using deprecated functions is an inconvenience as people will notice them
and wonder if there is a problem there.

In the case the dir file is compressed, we close the temp file before
launching the compression program with popen, meaning we don't get the
benefits of mkstemp versus mktemp, but the mktemp(3) man page sternly
commands, "Never use this function."

We could go to more efforts and have alternative code to
create the pipe (maybe following what is done in info/man.c
(get_manpage_from_formatter)), but I've little interest in this unless
there is evidence of a genuine problem.

It would help if people could test the change (commits 93162b78d84f7317
and ae3ffd40322).

--- a/install-info/install-info.c
+++ b/install-info/install-info.c
@@ -923,14 +923,19 @@ output_dirfile (char *dirfile, int dir_nlines, struct 
line_data *dir_lines,
   int n_entries_added = 0;
   int i;
   FILE *output;
+  int tempfile; /* moved to dirfile when finished */
+  char tempname[] = "infodirXXXXXX";
 
+  tempfile = mkstemp (tempname);
   if (compression_program)
     {
-      char *command = concat (compression_program, ">", dirfile);
+      char *command;
+      close (tempfile);
+      command = concat (compression_program, ">", tempname);
       output = popen (command, "w");
     }
   else
-    output = fopen (dirfile, "w");
+    output = fdopen (tempfile, "w");
 
   if (!output)
     {
@@ -1045,6 +1050,11 @@ output_dirfile (char *dirfile, int dir_nlines, struct 
line_data *dir_lines,
     pclose (output);
   else
     fclose (output);
+
+  /* Update dir file atomically.  This stops the dir file being corrupted
+     if install-info is interrupted. */
+  if (rename (tempname, dirfile) == -1)
+    perror (tempname);
 }





reply via email to

[Prev in Thread] Current Thread [Next in Thread]