On 05/27/08, Darren J Moffat wrote:
> Raymond Xiong wrote:
> > On 05/23/08, Darren J Moffat wrote:
> >> John Fischer wrote:
> >>> ==========
> >>>
> >>> On OpenSolaris, the public interface to start and stop
> >>> ejabberd will be SMF and the service will be named:
> >>>
> >>> svc:/network/xmpp:ejabberd
> >>>
> >>> Note that user will still need ejabberdctl(1M) for other
> >>> administration tasks(ie., user management).
> >>>
> >>> ejabberd listens on three TCP ports by default:
> >>>
> >>> 5222 - standard port for jabber-client protocol
> >>> 5269 - standard port for jabber-server protocol for
> >>> server to server connections
> >>> 5280 - port for ejabberd web-based admin
> >> I assume you don't actually mean "in a default install" but "When
> >> ejabberd is explicitly enabled". I'm assuming (hopefully) that ejabberd
> >> service is delivered disabled.
> >
> > Yes. ejabberd service will be disabled by default. The above ports
> > are default values and can be changed in its configuration.
> >
> >> What SMF method credential use ejabberd run with ? I'm assuming it is
> >> running as the daemon (or noaccess) user with no additional privileges.
> >> Given it is running on ports > 1024 it shouldn't need any privileges.
> >> [Strong HINT: I will derail this case if the answer is that it is
> >> running as root with all privileges]
> >>
> >> Which uid/gid owns the default log file location ?
> >>
> >> Which RBAC profile is the /usr/sbin/ejabberdctl in ?
> >>
> >> What new authorisations are added (and to which RBAC profile) for the
> >> SMF level administration ?
> >
> > Thanks for pointing out those issues(I wasn't aware of them).
> > I'd like to propose the following more:
> >
> > - a new user "ejabberd"(uid: 96) and a new group "ejabberd"(gid: 96)
> > will be added for running ejabbered service.
> >
> > (Notes: 1) I noticied mysql service uses "mysql" user, and postgresql
> > service uses "postgres" role. So I suppose it is OK to use either
> > user or role for this purpose. 2) svctag's uid is 95. So I use 96
> > for ejabberd.)
>
> I don't see why a new user account is actually necessary in this case so
> no I don't think it is oay.
>
> > - "ejabberd" user will be associated with "Ejabberd Administration"
> > profile, which includes solaris.smf.manage.ejabberd and
> > solaris.smf.value.ejabberd authorizations.
> >
> > - The above two authorizations are required for executing methods
> > in ejabberd service manifest.
> >
> > Note that ejabberd's initial configuration data are stored in config
> > files under /etc/ejabberd, so even with above proposal, root user is
> > still required for editting those config files(I suppose that is OK).
>
> Given the above I see no rationale for having an ejabberd user/role
> instead of using the daemon account.
Darren,
Here is my new proposal:
- Method credential for ejabberd SMF service will be "daemon" user
and "daemon" group. So, all files generated at runtime will have
daemon as their uid and gid.
- A new profile "Ejabberd Administration" will be created, which
includes two authorizations: solaris.smf.manage.ejabberd and
solaris.smf.value.ejabberd. The profile will also have
"euid=1;egid=1" execution attribute for ejabberdctl(1M) command.
- The above two authorizations are required to invoke ejabbered
service methods.
So by default, only root will be able to start/stop ejabberd. For any
other users/roles, they will need to have "Ejabberd Administration"
profile for that.
ejabberdctl(1M) is used for other administration tasks. What it does
is to attach a remote shell the specified Erlang node(that is, an
Erlang VM) and sends command to ejabberd modules. Because Erlang
protects acess to nodes with a cookie file, which is only accessible
by the one who starts the server, so I assign "euid=1;egid=1" attribute
to the command in the profile.
Thanks,
Raymond
