Jeff's mail got dropped by the filter on opensolaris-arc.  Please
do not reply to this email (it will not go to all the interested
parties).


------- Forwarded Message

Date: Wed, 28 Feb 2007 13:15:39 -0500
From: Jeffrey Hutzelman <[email protected]>
Subject: Re: [security-discuss] Re: PSARC/2003/674 [restart] pam_list module
In-reply-to: <200702281745.l1SHjFvx012263 at marduk.eng.sun.com>
To: Gary Winiger <gww at eng.sun.com>, Darren.Moffat at sun.com
Cc: psarc-ext at sun.com, Satish.Murugesan at sun.com,
 security-discuss at opensolaris.org, Jeffrey Hutzelman <jhutz at cmu.edu>
Message-id: <1F0767552E0B0A347A38A628 at sirius.fac.cs.cmu.edu>


On Wednesday, February 28, 2007 09:45:15 AM -0800 Gary Winiger 
<gww at eng.sun.com> wrote:

>       Not saying the CU be damned, but just the opposite.  IMO, as
>       I believe I stated this 3.5 years ago when this started, this
>       project is kludge/bandaid for lack of a proper architecture.
>       I'm saddened that such an architecture doesn't seem to be
>       forthcoming.

Part of the issue is that not all customers want a "proper architecture" 
with complex databases that can only be updated by running obscure, 
platform-dependent programs.  Some of us maintain large numbers of machines 
(1000+ in my case; orders of magnitude more for some of the customers 
mentioned), and we mostly do it using portable tools that maintain the 
contents of the filesystem.

The master repository says what the system must look like, and the tool 
makes it so.  Every time you introduce a database which can only be updated 
through some new interface, I have to write a helper program that attempts 
to use that interface to compare the current contents of the database to 
what my repository says should be there, and make the required changes.

Installing a new inetd.conf and sending a SIGHUP is way easier than trying 
to update smf.  And no, the conversion program Sun provides doesn't help 
here, because it doesn't recognize when it needs to _delete_ a service 
that's not in the input file.  Just to make it more fun, several of the 
services that ship with Solaris use different names than those which would 
be used by the inetd.conf converter, for no apparent reason.


So, while I likely won't be using the authorization mechanism currently 
under discussion, if I did, I'd want it to work exactly as described - let 
me provide a file which describes what needs to be done.  Changes to that 
file are logged and audited elsewhere.

-- Jeff

------- End of Forwarded Message


Reply via email to