www.delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/1998/02/06/20:26:35

From: cgf AT bbc DOT com (Christopher Faylor)
Subject: Re: Changing dll name -> cygwinb19.dll
6 Feb 1998 20:26:35 -0800 :
Message-ID: <Enzon7.CMr.cygnus.cygwin32.developers@bbc.com>
References: <Enyor5 DOT 2Ks AT bbc DOT com>
Reply-To: cygwin32-developers AT cygnus DOT com
To: cygwin32-developers AT cygnus DOT com

In article <199802070221 DOT SAA01950 AT rtl DOT cygnus DOT com>,
Geoffrey Noer  <cygwin32-developers AT cygnus DOT com> wrote:
>Christopher Faylor wrote:
>> 
>> How about exporting lock_pinfo and unlock_pinfo so ps.cc can use it?
>> Then it can lock the process table while it is scanning it and theoretically
>> avoid some occasional weird output.
>
>Hmmm...  Not that we don't have other security holes, but this would
>mean that anyone could hang Cygwin32 trivially which I don't like very
>much.  :-(

Wouldn't this only affect a specific user's mutex?

Nevermind.  It is so trivial that if there is a hint of a security
problem, it is not worth investigating.

>I think a better solution here would be to make the process info
>available via an exported function(s?) which would take care of the
>locking internally.
>
>This may well be not worth the effort, however.

Nope.  A functional interface into pinfo_list would be nice and would
remove the requirement of recompiling ps.cc when the structure changes
but... why bother?
-- 
http://www.bbc.com/	cgf AT bbc DOT com			"Strange how unreal
VMS=>UNIX Solutions	Boston Business Computing	 the real can be."

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019