Hi Liane, > As a beginning note, there's nothing in the SMF > architecture or > implementation which requires methods be put into > /lib/svc/method.
Yes, that's why I'm changing all my packages to use /etc/svc/method. However, I don't wanna re-invent the wheel, i.e. repackage all bogus packages, just because it was not considered, that the package might be installed into one non-global zone, only (hint to install-discuss, which says, that this is not an install/packaging issue)... > /lib was chosen because it is available before /usr > is mounted, and /etc is also available before /usr gets mounted. > IIRC the Solaris rules (per filesystem(5)) say that > /etc is for > configuration, not executables. But, it's late and I > may be > misremembering. It also says "An approved installation location for bundled Solaris software..." And anyway, startup scripts where located for decades in /etc/init.d and at least other *x still use it for their startup scripts (and probably will not change that, just because SUN thought, it must be different). So far to to [pseudo] standards. Also SUN breaks this guideline/rule?/contract? (/etc: conf files, only) several times: see find /etc -type f -perm -u+x So, the argument is IMHO at most a pretty theoretical justification and not practice oriented. > SUNWsndmu installs the sendmail binary into a > read-only location, > /usr/lib/sendmail. So, you've installed SUNWsndmu > into the global zone/ > all zones? And, the package you're trying to control > is SUNWsndmr, > which you want to avoid installing in all local > zones? So you're > OK with having the service binaries in the zones, and > you just don't > want the service to run except on zones you > specifically select? Sorry, no. (BTW: Actually it doesn't matter, which package we refer to. However, SUNWsndm* is one example, which shows the problem). The case one will usually find something like is: Global zone: pkgrm SUNWsndmu SUNWsendmr sparse zone: pkgadd SUNWsndmu SUNWsendmr Whereby SUNWsndm* should be considered as the placeholder for the questionable/unsecure/"have a bad feeling", but required software - i.e. actually the reason, why one has choosen to setup the zone. So one does not want to have the software installed neither in the global zone nor in all other existing none-global zone. Furthermore (kind of OT): Some people/unexperienced user might think, installing the package in the global zone, inherited it and just disable the unwanted service might be safe. But as more experienced users know, just having a service not running does not prevent anybody to executed a program. And thus a security threat might still exists. E.g. suid xterm, suid sendmail and who knows, which other software falls or may fall into the "security risk" category tomorrow ... So best practice is probably still: Do not install any software, you do not need (at least on servers ;-)) ... And now, we're back: Installing SUNWsndm* correctly in a sparse zone is right now impossible - because of /lib/svc/method/smtp-sendmail ; the flawed /var/svc/manifest/network/smtp-sendmail.xml ... Regards, jens. This message posted from opensolaris.org
