Date: Tue, 12 Mar 2002 05:58:44 -0600 From: "Matthew D. Fuller" <fullermd@over-yonder.net> To: hackers@freebsd.org Subject: [fullermd@over-yonder.net: Re: bug in pw, freebsd 4.5] Message-ID: <20020312055844.K57293@over-yonder.net>
next in thread | raw e-mail | index | archive | help
Come to think of it, -hackers may be the more appropriate forum for RFC'ing on this... ----- Forwarded message from "Matthew D. Fuller" <fullermd@over-yonder.net> ----- From: "Matthew D. Fuller" <fullermd@over-yonder.net> To: Daniel Sickels <oreh@eznet.net> Cc: freebsd-bugs@FreeBSD.ORG Date: Sat, 9 Mar 2002 04:52:25 -0600 Subject: Re: bug in pw, freebsd 4.5 User-Agent: Mutt/1.2.5-fullermd.1i Message-ID: <20020309045225.D57293@over-yonder.net> On Fri, Mar 08, 2002 at 12:43:51PM -0500 I heard the voice of Daniel Sickels, and lo! it spake thus: > Multiple instances of pw making chanegs at the same time cause some rather > horrid things to happen. The master.passwd file can be quite badly > corrupted, or pwd_mkdb can fail. This bug is easily reproducable with a > 10000+ line master.passwd, using: > pw useradd test1; pw userdel test1 > ten times over in one process, and > pw useradd test2; pw userdel test2 > ten times over at the same time. The reason for this is that the only file pw(8) locks is /etc/master.passwd.new when it copies into it. It can't lock master.passwd, because that file will disappear and reappear in the middle of its work. I suppose in THEORY you could change the master.passwd -> internal fudging -> master.passwd.new -> rename(master.passwd.new, master.passwd) into .... -> ftruncate(master.passwd), master.passwd.new copy into master.passwd, but that seems rather ugly. I think the correct (well, the least incorrect, anyway) solution is to use an external lockfile for dealings with the passwd file. From a look at hier(8), /var/run seems the most appropriate place. pwd_mkdb(8) and vipw(8) would need to be made to use that location too, and I think pwd_mkdb(8) may need to have a flag added to NOT lock (since pw(8) calls pwd_mkdb(8) internally, it would have to hold the lock the whole time so as to avoid opening a race window). If anybody's interested, I could take a stab at hacking something together for this sometime over the next week or so. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Unix Systems Administrator | fullermd@futuresouth.com Specializing in FreeBSD | http://www.over-yonder.net/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message ----- End forwarded message ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020312055844.K57293>