Nicolas Williams wrote:
> I don't want to add to the fire, but I think we can SUMMARIZE the
> situation for AT&T, applications of AST outside AT&T or the OS, and Sun
> as:
...
> b) Solaris has never delivered the AST libcmd before, THEREFORE...
>
> c) ...changing the path of this shared object in
Darren J Moffat wrote:
> Attached is my swag on what is and is not a service, 64% or the 28 files
> on the snv_46 system I looked at could in opinion could be stored in SMF.
Add:
cdrecordNot a service
readcd Not a service
cddawav Not a service
starNot a s
>login Not a Service - looks like it but isn't
>passwd Not a Service
>su Not a Service
>sys-suspendNot sure on this one, there might be a better RBAC way
Specifically for the first three of these, much of similar configuration
lives
Joseph Kowalski wrote:
>> From: Alan Coopersmith
> ...
>> Nicolas Williams wrote:
>>> IMO def*() should be contracted for using existing default files (and
>>> variables) *only*.
>>>
>>> For example, if there was a new GUI utility that needed to process
>>> /etc/default/su in order to be consisten
On Wed, 27 Sep 2006 14:20:39 +0200 Joerg.Schilling at fokus.fraunhofer.de
(Joerg Schilling) wrote:
> >From my understanding, the cleanes way would be to out ksh::libcmd into
> /usr/lib/ksh/ or /usr/lib/ast/ without merging with sun/att::libcmd.
> There is no source issue as you only need to chan
Casper.Dik at Sun.COM wrote:
>
> >The updated proposal lists the files that will be in root.
> >
> >Yes, the root files are only libcmd and libast:
> >/lib/libcmd*, /lib/{amd64,sparcv9}/libcmd*
> >/lib/libast*, and /lib/{amd64,sparcv9/libast*.
>
> And please make sure it is lazyloaded (libcmd is
On Wed, Sep 27, 2006 at 01:25:58AM +0200, Joerg Schilling wrote:
> A different issue (for mixing sun/att::libcmd and ksh::libcmd) may be the
> fact
> that libcmd is used by many security relevent tools such as su and pfexec.
Good point!
Will the AST libcmd have an .init section that does anythi
On Tue, Sep 26, 2006 at 01:44:12PM -0700, Alan Coopersmith wrote:
> Nicolas Williams wrote:
> >IMO def*() should be contracted for using existing default files (and
> >variables) *only*.
> >
> >For example, if there was a new GUI utility that needed to process
> >/etc/default/su in order to be cons
David Korn wrote:
> First let me say that I do not understand all the implications
> of the various terminology such as SWF, ON, or what it
> means to be in a specific "consolidation".
The entire Solaris OS is too big to manage as one huge chunk of
code, so it is broken down into "consolidations".
Nicolas Williams wrote:
> IMO def*() should be contracted for using existing default files (and
> variables) *only*.
>
> For example, if there was a new GUI utility that needed to process
> /etc/default/su in order to be consistent with su(1) then it should use
> libcmd:def*() under contract, but
> From: Alan Coopersmith
...
> Nicolas Williams wrote:
> > IMO def*() should be contracted for using existing default files (and
> > variables) *only*.
> >
> > For example, if there was a new GUI utility that needed to process
> > /etc/default/su in order to be consistent with su(1) then it shou
11 matches
Mail list logo
