Amanda Waite wrote: > > The second hole is RBAC. How do I add entries to prof_attr and exec_attr > in /etc/security via a package install without a script? I assume that > this is straightforward and that I just simply don't know the answer.
Unfortunately no, turns out there isn't any way of doing it from your package... Add yourself to the cc list of this bug to track progress on that front: http://defect.opensolaris.org/bz/show_bug.cgi?id=217 Meanwhile the only workaround is to add them globally. Look at the files in usr/src/common/rbac/ in sfw, look at MySQL examples, for instance. This does mean they will be present in the system even if lighttpd package is not installed, which doesn't make much sense. Worse, it also means they won't show up by merely installing the lighttpd package, which will be a problem. But, that's the only workaround right now. > I think I get this and have followed the example of the MySQL Arc Case. > The worry I have is that I'm not sure how best to document these things > in the available columns and how to determine what their stability is. > Can someone advise. Just document what makes sense.. if you expect to document and support users who programmatically depend on "it" (whether "it" is the path to the executable or an API or CLI option flags or an exist code or whatever else), list it as an interface. As to the stability, that's more complicated but you need to balance the input from the upstream community as to its stability vs. the track record of the upstream community in that stability vs. the usability of the component if too many interfaces are too volatile vs. the added stability-value your team can provide. With third party open source components it is a balancing act. That's just the generic advice... If you want to bring up specific interfaces of lighttpd for discussion please do. -- Jyri J. Virkki - jyri.virkki at sun.com - Sun Microsystems
