[csw-maintainers] CSWcswclassutils: it wants to write in /usr

[Philip Brown]

On Fri, Dec 18, 2009 at 2:08 PM, Sebastian Kayser <skayser at opencsw.org> wrote:
> Philip Brown wrote on 18.12.2009 22:22:
>>
>>
>> I would guess you mean "suppress postinstall scripts" warnings.
>
> No, I specifically meant suppress CAS warnings. Please see below.

Hm. things are getting long, so I think it would be beneficial to
restate in full your proposal, and perhaps it will actually take up
less space that way :)
What I believe you are suggesting, is as follows:

 - We still use things such as
f cswpreserveconf /etc/opt/csw/yourprog.cnf.CSW 0444 root bin

however, the class action "cswpreserveconf", you are proposing be a
very dumb stub, included in every package, which would somehow hand
things off to /opt/csw/share/CSWUTILS/[...]

Since these are no longer "bundled/installed" class actions, they
would trigger class action warnings. Which you are then suggesting we
suppress by forcing an admin file, "dont prompt user about
questionable-security activities of packages".

that about sum it up?

I have two comments on this:
1. In some respects that seems only slightly different, from just
doing everything in postinstall scripts, that call "standard" csw
utils, rather than having everything inline.
I'm not sure it is strictly better than the simplistic postinstall way.


2. It requires having an admin disable LEGITIMATE warnings, to be
spared the prescreened trivial warnings.
(ie: you propose disable ALL class action script warnings, not just
warnings about the official csw pre-screened actions)

So, while your proposal does address the "single point of update"
issue, it still leaves the security issue open.

I will point out,that one of the reasons sun chose /usr/sadm to be the
official residence of approved class action utils, is exactly BECAUSE
it is often mounted read-only, in security-sensitive installations!!
it is expected, and encouraged, to only very rarely update things in
there, and thus to have detailed inspections and approvals for it when
they are.

(which as a side note, should serve as a reminder to us, to only
update cswclassutils infrequently, and to ensure 100% backward
compatibility for it)






>> I will propose an alternative, that came to me today while pondering
>> this problem. An alternative, would be for us to publish our own
>> version of the SVR4 pkg utils. This version would respect class action
>> scripts elsewhere, such as /opt/csw/[whereever]. [...] I imagine it
>> would be a considerable effort for someone to do this. Allegedly,
>> the source is out there somewhere... but you'd have to track it down
>> and make it useable.
>
> Sounds like a substantial effort to deliver/maintain and honestly, I as
> a sysadmin would not be willing to install 3rd party repackaged pkg*
> tools which directly deal with my package database.

you are not open to that, but you ARE perfectly happy with turning off
all security warnings when you add a package?
This policy seems to be a little... lacking.. to me :-}