>Date: Tue, 27 Jan 2009 16:21:06 -0500 >From: Jeffrey Hutzelman <jhutz at cmu.edu> >Subject: Re: Bug 6793488 - lofs passwd/shadow in labeled zones >To: Frank Batschulat <Frank.Batschulat at sun.com>, security-discuss at opensolaris.org >Cc: jhutz at cmu.edu > >--On Tuesday, January 27, 2009 08:05:45 AM -0800 Frank Batschulat ><Frank.Batschulat at Sun.COM> wrote: > >>> This bug, 6793488, has been created recently for a >>> case I have open with Sun Support. This is a very >>> severe case to me and my customer. I would like to >>> get it fixed as quickly as possible. I was told the >>> bug was dictating this case, which in turn, affects >>> the priority of my case being resolved. If this >>> affects others please add comments to this post. If >>> an engineer can also help it would be greatly >>> appreciated. Another bug similar to this one is >>> 6571565. Here are the links: >>> >>> http://bugs.opensolaris.org/view_bug.do?bug_id=6793488 >> >> Hey Josh, by accident I run across your posting. Since I'm the engineer >> who closed this bug as not a bug I'd like to share my reasoning with you >> that I've put into the bugs evaluation that is not visible to you. I hope >> this helps you to better understand the issue and overall picture. >> >> This is not a bug (tm), it is not a bug in lofs(7FS), not in ufs(7FS) >> and not in mv(1) either. > >Yup; the behavior described is how it's supposed to work. The key fact >that the submitter of 6793488 seems to have figured out but others may not >is that commands which update the passwd file do so by creating a new file, >then renaming it on top of the old one. The contents of the original file >are not changed. > >This is important because renaming a new file on top of the old one is an >atomic operation, while rewriting the contents is not. If the file is >rewritten, then there are points in time when another process looking at it >may see something other than the old or new contents, such as only the >first few lines of the new contents (that is assuming the rewrite is done >with O_TRUNC; otherwise the results could be even worse). Further, if the >system or even just the passwd command were to crash during the rewrite, >it's possible the file could be permanently broken in that way. That would >be Very Bad(tm). A rename doesn't have either of these problems, which is >why it's done that way. > >Note that this means that the workaround suggested in the bug report is a >poor one, because it has the same non-atomic behavior.
Actually it is a pretty good workaround if combined with: 1. Doing the copy very frequently 2. Basing the decision to copy upon diffs rather than date. 3. removing /usr/bin/passwd in the labeled zones The reason: The global zone's passwd file's atomic safety is being preserved using the original rules and the global zone is using that passwd file. The only things that get these unsafe copy operations are COPIES. If the global zone's passwd file is still good, then you can still log into TJDS or TCDE and you can still log into the global zone via the console (if enabled) -- so you can still get in to fix things. In addition, if the copy is set to run once every minute or two, any one bad copy will only last a minute or two, if the decision to copy is based upon diffs rather than on "-newer" logic. The reason for removing /usr/bin/passwd from the labeled zones is that it operates on the local end, instead of the global zone shadow file, so any changes get overmounted or discarded or something next zone reboot. (I have been unable to check the exact mechanism here because shutting down the zones does not appear to umount passwd and shadow.) >-- Jeff >_______________________________________________ >security-discuss mailing list >security-discuss at opensolaris.org @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Jan Parcel, Sustaining, Trusted OE
