Tetsuo Handa wrote:
> Jamie Nguyen wrote:
>> > "move_namespace" might replace "initialize_domain".
>>
>> What is your suggested syntax/usage for "move_namespace" and
>> "no_move_namespace" ?
>
> Same with "initialize_domain"/"no_initialize_domain". For example,
> "move_namespace /usr/sbin/httpd from any" will transit to "</usr/sbin/httpd>"
> namespace when /usr/sbin/httpd is executed. If we want to specify namespace to
> transit to, we can't reuse syntax/parser for 
> "initialize_domain"/"keep_domain".

I'm worried that this may potentially be quite confusing for new
users. They already have to try to understand the concept of "domains"
but now also have to understand the concept of "namespaces". I think
it is often best to make it possible for new features to be ignored if
users don't need them, but I'm not sure if this is possible here.

Also, concerning the directive syntax, how about using
"initialize_namespace" instead? This might be more easily recognisable
as a drop-in replacement for "initialize_domain" and easier for
existing users to get used to.


> auto_domain_transition="<httpd>" in ACL's condition part will transit to
> "<httpd>" namespace whereas auto_domain_transition="/usr/sbin/httpd" in ACL's
> condition part will transit to "current domainname" + "/usr/sbin/httpd" 
> domain.
>
>
>
> task auto_domain_transition <apache> will transit to "<apache>" namespace
> if current namespace is not "<apache>", will transit to "<apache>" domain
> otherwise.
>
>
>
> If we want to use different keywords (like 'auto_namespace_transition="httpd"'
> and 'task auto_namespace_transition apache' ) for easier understanding,
> I can do so.

This directive can result in transition to either a domain or a
namespace, so both "auto_domain_transition" and
"auto_namespace_transition" don't describe perfectly. So I think it is
best to stick with "auto_domain_transition" to keep syntax familiar.
It also functions in exactly the same way unless <$namespace> is
specified, which makes it easier for users to ignore namespace
functionality.

_______________________________________________
tomoyo-dev-en mailing list
tomoyo-dev-en@lists.sourceforge.jp
http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev-en

Reply via email to