>The method we use here is the same method you'll find on pretty much all >of the linux variants out there, so it really can't be that bad. And as >I also said in another message: memcached is by design insecure and you >should therefore _only_ run it in your private and secure network.
Consider this scenario. An OpenSolaris host has a Systems Administrator, who can do everything. It also has a Database/Memcache administrator that does not know the root password, but has privileges through RBAC to control the services he/she needs to administer. Part of those authorizations are supplied from your manifest in the forms of "solaris.smf.manage.memcached" and "solaris.smf.value.memcached". So, the database administrator can set the "-m" option, or the "-p" option or whatever, or they can change the user through the "-u" option. When SMF starts memcache, by defaut it starts it as root. Then, because of your default "-u noaccess" option, Memcache changes its effective ID to "noaccess". But if the database administrator changes memcached/options to "-u root", then the command line becomes: $ memcached -u noaccess -u root Guess what happens? Memcache runs as root. So a user that never had root access now has control over a program running as root. Memcache doesn't write out any files, and it doesn't read any files, but I'd think you understand where my logic is heading. But with a <method_context> block, memcache never has the opportunities to have root privileges. -- This message posted from opensolaris.org
