summaryrefslogtreecommitdiffstats
path: root/pw/fileupd.c
diff options
context:
space:
mode:
authorNate Williams <nate@FreeBSD.org>1998-07-16 17:18:25 +0000
committerNate Williams <nate@FreeBSD.org>1998-07-16 17:18:25 +0000
commit953e54b3c1853cbc2a959f96455184ffb137b124 (patch)
tree9fc0a883af71bc75dd6293dd3a4f8cd6e974e1ea /pw/fileupd.c
parent5f7820db4e9629fa29eb39fecc10ab190a7d1da5 (diff)
downloadpw-darwin-953e54b3c1853cbc2a959f96455184ffb137b124.tar.gz
pw-darwin-953e54b3c1853cbc2a959f96455184ffb137b124.tar.zst
pw-darwin-953e54b3c1853cbc2a959f96455184ffb137b124.zip
Fix race condition in pw caused by multiple instances of pwd_mkdb being
run at the same time. Notes: The fileupdate function is still somewhat broken. Instead of returning a failure code if it can't modify the original file it renames the .new file and continues as though nothing is wrong. This will cause the lock on the original file to be lost and could lead to a similar race condition. I left that portion of the code alone since I feel that the maintainer of the code would have a better concept of how he wants to handle errors in that function than I do. PR: bin/6787 Submitted by: Craig Spannring <cts@internetcds.com>
Diffstat (limited to 'pw/fileupd.c')
-rw-r--r--pw/fileupd.c17
1 files changed, 14 insertions, 3 deletions
diff --git a/pw/fileupd.c b/pw/fileupd.c
index 3782bf7..fe46480 100644
--- a/pw/fileupd.c
+++ b/pw/fileupd.c
@@ -26,7 +26,7 @@
#ifndef lint
static const char rcsid[] =
- "$Id$";
+ "$Id: fileupd.c,v 1.5 1997/10/10 06:23:31 charnier Exp $";
#endif /* not lint */
#include <stdio.h>
@@ -76,7 +76,7 @@ fileupdate(char const * filename, mode_t fmode, char const * newline, char const
if (pfxlen <= 1)
errno = EINVAL;
else {
- int infd = open(filename, O_RDWR | O_CREAT | O_EXLOCK, fmode);
+ int infd = open(filename, O_RDWR | O_CREAT, fmode);
if (infd != -1) {
FILE *infp = fdopen(infd, "r+");
@@ -168,9 +168,20 @@ fileupdate(char const * filename, mode_t fmode, char const * newline, char const
fputs(line, infp);
/*
+ * If there was a problem with copying
+ * we will just rename 'file.new'
+ * to 'file'.
* This is a gross hack, but we may have
* corrupted the original file
- * Unfortunately, it will lose the inode.
+ * Unfortunately, it will lose the inode
+ * and hence the lock.
+ *
+ * The implications of this is that this invocation of pw
+ * won't have the file locked and concurrent copies
+ * of pw, vipw etc could clobber what this one is doing.
+ *
+ * It should probably just return an error instead
+ * of going on like nothing is wrong.
*/
if (fflush(infp) == EOF || ferror(infp))
rc = rename(file, filename) == 0;