On Tue, 06 Jan 2009 13:19:46 -0500
"Anurag S. Maskey" <Anurag.Maskey at Sun.COM> wrote:
[...]
> I started with enforcing read-only at the CLI, then came across the
> enforcement of automatic NCP in the library. I decided that making the
> CLI dumb and enforcing read-only (either when the property read-only is
> true or for the automatic NCP) at the library (also extended the opaque
> handle to include a read-only flag).
>
> This requires that the library be able to distinguish calls from nwamd
I believe this is unnecessary. The point is not protection against
maliciousness but implementation of policy.
> (which can override the automatic NCP read-onlyness). Some library
> functions have flags and can take the NWAM_FLAG_OKAY_TO_WRITE, but other
> functions can't (like set, create, etc) can't.
>
> I can go with enforcing read-only properties and read-only NCP's at the
> CLI level. In this case, should the library even have the OKAY_TO_WRITE
> flag? If this flag is around, it creates confusion as set, create,
> delete have to be enforced by consumers, but commit and destroy are
> enforced by the library. Either move all the enforcement to the library
> or to the consumer seems like cleaner solutions.
Yes. A mixed solution doesn't make any sense to me.
>
> I prefer the enforcement in the library, but will need to extend the API
> of the library (mainly nwam_ncu_create(), nwam_ncu_set_prop_value(),
> nwam_ncu_delete_prop()) to include flags (just like nwam_ncu_commit()
> and nwam_ncu_destroy()).
If that is what you prefer then that is what you will need to do.
mph
>
> Thanks,
> Anurag
>
