Subject: Re: pwlock and sound stuff

From: "Charles M. Hannum" <[email-masked]>

(Interesting, though, that there is actual locking on the file instead
    of using /etc/ptmp as the lock and the working file at the same time...)

That's unreliable if you use (e.g.) Emacs, since there is a race
condition when saving the file when no file with the correct name
exists.

---

From: Chief Anarchic Officer <[email-masked]>

Really.  (?!?)

Does that mean that if this happens (assume working pseudocalls :-)):

# vipw
        copy("/etc/mpasswd", "/etc/ptmp");
        edit("/etc/ptmp");
        /* insert error checking here */
        if (no_errors)
                rename("/etc/ptmp","/etc/mpasswd");
#

...somewhere in there is a race condition?  On a COPY, where the file
exists in two places at once?

Sounds like something is broken.

--
 _______Wizardry is dead._____ _____WHO: Greywolf (my nameplate even says so)
/ ___\ _ \ __\ V / \  / /__ \| | __/WHAT: UNIX System Mangler...er, Admin
\ \| |   < _| ` ' \ '` / \/ /|_| _/ WHERE: Autodesk, Inc.  3 Harbor Dr.
 \___|_|\_\__\|_|  \/\/ \__/___/_|  Sausalito, CA 94965 (415) 332-2344 x4219
	see also: [email-masked]

---

From: der Mouse <[email-masked]>

> ...somewhere in there is a race condition?

Yes, precisely.  (I am assuming that copy() errors out if its target
exists.)

The danger: person 1, using emacs (say), does this.  During the edit()
call, person 1 saves.  Emacs does a rename("/etc/ptmp","/etc/ptmp~")
or whatever backup format has been chosen by that user, then writes out
the buffer to /etc/ptmp.  But after the rename and before the open for
the write, person 2 fires up vipw.  It finds /etc/ptmp nonexistent and
hence proceeds.  I'm sure you can fill in the rest.

Thus, some other sort of locking by vipw is somewhere between desirable
and critical, depending on how much you value the integrity of your
password database...and whether you have or may get editors that, like
at lest some versions of emacs, can cause a file to be nonexistent
briefly during normal operation.

Of course, if open() had an O_UNLINKFIRST flag bit, to do an unlink()
and open() atomically, then this style of backup could be done safely
with respect to this danger...but it doesn't.

					der Mouse

			    [email-masked]