Michael Hunter wrote: > On Tue, 13 Jan 2009 20:53:49 +0000 > Alan Maguire <Alan.Maguire at Sun.COM> wrote: > > [...] > >> not. It occurred to me that since what we really want >> to do is to restrict modification of these objects >> to nwamd itself, would it maybe make sense >> rather than having a readonly property >> to simply do a check of the uid of the library >> caller - if it matches the netcfg uid (that nwamd >> runs as) we can modify the automatic NCP, otherwise >> we can't. Anurag pointed out that if this was the >> approach we took, we could simply su >> to the netcfg user and modify things via nwamcfg, >> but I don't know if that's a major problem. What do >> you think? >> > [...] > > Either method seems acceptable to me. You are not attempting to > restrict maliciousness but allow the sane user of the API to be > communicated an attribute of an object which tells the intended use of > that object. Right. > I think this attribute of the object should be part of > the object and not part of some meta information. What's your take on the visibility of the read-only property in the UI? At present, it's visible to users when they create objects, and outside of the automatic NCP it can be toggled. I don't see any great value in allowing users to create read-only objects via nwamcfg - am I missing use cases that others have envisaged though? Thanks!
Alan
