Date: Thu, 2 Aug 2001 20:55:38 +0300 From: Peter Pentchev <roam@orbitel.bg> To: Jim Sander <jim@federation.addy.com> Cc: freebsd-security@FreeBSD.ORG Subject: Re: RELEASE 4.3 -> RELENG_4_3: SUCCESSFULLY but ... Message-ID: <20010802205538.B11105@ringworld.oblivion.bg> In-Reply-To: <Pine.BSF.4.10.10108011712010.76480-100000@federation.addy.com>; from jim@federation.addy.com on Thu, Aug 02, 2001 at 11:53:52AM -0400 References: <20010801220141.C2354@gateway.bogus> <Pine.BSF.4.10.10108011712010.76480-100000@federation.addy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Aug 02, 2001 at 11:53:52AM -0400, Jim Sander wrote: > > Someone wrote: > > My question is: what is the real danger of doing `installworld` in > > multiuser mode? I have doing a lot of tests in other machines tracking > > STABLE and I have no problems so far. > > >> Someone else replied: > >> They advice you to run singleuser, because of the securelevel. > > It's more than that I think... It is, but mostly not in the way you think :) > I *believe* that it is *theoretically* possible that a binary copy of a > library could change in a way that makes it incompatible with running > processes that link to it. (for instance, if the library changes the > number of arguments a function expects) It is possible - say you change the *type* of the first argument :) However, both the situations you described - number of arguments changing - and the situation I described - type of arguments changing - fall into the case of changing functionality. With shared libraries, whenever the functionality of the 'important' functions is changed, the library version number is bumped. Thus, processes linked against the older version still get the older functionality, while newly linked processes, which have been compiled and linked against the new headers/library, know how to use the new calling conventions. So, this is not much of a problem. The problem lies more in the fact that there are processes running at the very moment the library files are replaced. Although install(1) generally does a great job at atomically replacing files, sometimes I've noticed a couple of processes complain about being unable to access libraries, if the processes happen to call a library function at the precise moment the library is being overwritten. This may cause important processes to fail, possibly in a disastrous way, possibly going haywire and doing random disk writes. This, I believe, is part of the reason that it is recommended that the installworld phase be performed in single user mode, so that there are no dynamically-linked background processes running, and the only dynamically-linked processes are the ones involved in the installation itself. > Obviously this could cause "instability" in said processes, if not the > kernel. That in turn could cause the failure of the install process. If > things blew up badly enough, even a reboot wouldn't fix the problem and > you'd be totally hosed. (the key here is to make sure the install process > finishes cleanly- if it doesn't, all bets are off) > > The only time I suspect this sort of thing would be a real problem is > if you did an "in place" major-revision upgrade (from 2.x to 3.x etc.) > because the libraries underwent major changes. But I'm not experienced > enough to say that with any authority. As explained above, a glitch might happen during any normal update of a library :( > Any superior real-world experience or detailed technical knowledge to > contradict or modify the above is of course welcome. I wouldn't really call my experiences 'superior' or 'technical' - I never really bothered to see just *why* was install(1) not atomically replacing my libs :) G'luck, Peter -- "yields falsehood, when appended to its quotation." yields falsehood, when appended to its quotation. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010802205538.B11105>