Darren Reed wrote:
> Darren J Moffat wrote:
>> Darren Reed wrote:
>>> Darren J Moffat wrote:
>>>> Rather than SUNW as a prefix why not "org.opensolaris." or "com.sun" ?
>>>
>>> I've no strong opinion about this ...
>>> do we have some internal structure for such names?
>>>
>>> "com.sun.inetd" seems too.... "broad" for my liking...
>>> "com.sun.solaris.inetd" might be a better/tighter fit.
>>
>> or even just "solaris.inetd" which matches the hierarchy used for RBAC
>> authorisations.
>
> That crossed my mind, but I wasn't sure if it would be desirable
> to have two name spaces that look the same but are for different
> purposes. Someone might assume that a project named "solaris.inetd"
> meant there was an RBAC authroisation or that if there was an RBAC
> authorisation called "solaris.inetd" that it referred to the same
> object as the project name. Good engineering would suggest that a
> project called "solaris.inetd" wasn't used for sendmail and simiarly
> that an RBAC authorisation bearing the same name also didn't refer
> to something that wasn't inetd...
>
> I don't mind updating the spec to say that names are "solaris.*"
> and that if there's already an RBAC name for that object then the
> project must bear the same name. Also if there isn't an exact match
> in the RBAC names that the name must otherwise fit into the RBAC
> naming heirarchy. Thus solaris.inetd would become
> "solaris.network.inetd".
>
I agree that "solaris." is a good prefix for reserved project names. I
don't think there necessarily needs to be a connection between the
project name and any authorizations that might be used by software
running under that project id.
In particular, I recommend using the single "solaris." prefix in the
same way that "SUNW" was suggested earlier and *not* trying to create
hierarchical project names like "solaris.network.inetd". The latter
usage at least suggests the existence of a higher-level solaris.network
project that limits the resources of all the solaris.network.* projects.
Scott
--
Scott Rotondo
Principal Engineer, Solaris Security Technologies
President, Trusted Computing Group
Phone/FAX: +1 408 850 3655 (Internal x68278)
