Tetsuo Handa wrote:
> Well, I think we will need to choose one from choices listed below:
>
> (1) implicitly use the basename of the program (e.g. httpd for
> "initialize_namespace /usr/sbin/httpd from any" case)
>
> (2) let users explicitly specify the namespace (e.g. apache for
> "initialize_namespace apache /usr/sbin/httpd from any" case)
>
> (3) use escape (e.g. \057usr\057sbin\057httpd for /usr/sbin/httpd )
> like AppArmor does (i.e. replace '/' with '.')
>
> when accessing namespace directories.
If we use (1) then there is the possibility that 2 namespaces might
conflict, such as /usr/bin/foo and /usr/lib/foo . Can we do (3) by
default and let (2) also be possible? If we allow (2) then I guess we
either have to disallow "/", or automatically convert "/" to "." .
Also, are you planning on allowing a sub-level namespace (e.g.
<.usr.sbin.lxc>) to have a further sub-sub-level namespace? And how
are you planning to handle display of namespaces in ccs-editpolicy?
Will it look something like this (indenting sub-level namespaces to
indicate it's parent namespace):
<kernel>
* /sbin/init
/etc/rc.sysinit
....
....
* /usr/sbin/httpd
....
....
<.usr.sbin.lxc>
* /sbin/init
/etc/rc.sysinit
....
....
> As you locate $namespace directory under $YY-$MM-$DD.$hh:$mm:$ss directory,
> you prefer saving all namespace's policy files atomically over saving
> individual namespace's policy files as needed, don't you?
Yes, much less complicated to perform saving of everything at the same
time. Also, sub-level namespace (e.g. <apache>) policy is meaningless
without top-level namespace (e.g. <kernel>) policy, as top-level
namespace decides what domains transit to the sub-level namespace.
> Do we locate policy files for kernel namespace to
> /etc/ccs/policy/$YY-$MM-$DD.$hh:$mm:$ss/ and retain 4 symlinks in /etc/ccs/ ?
> This is good for backward compatibility, but may cause operation mistakes
> (e.g.
> adding to kernel namespace while meant to add to apache namespace) when users
> started using other namespaces. In this case, $namespace is none of 'kernel'
> 'domain_policy.conf' 'exception_policy.conf' 'profile.conf' 'manager.conf'.
>
> If locate policy files for kernel namespace to
> /etc/ccs/policy/$YY-$MM-$DD.$hh:$mm:$ss/kernel/ and remove 4 symlinks in
> /etc/ccs/ , this breaks backward compatibility but may help avoiding
> operation mistakes. In this case, $namespace can be any word.
Alternatively we could create "/etc/ccs/namespace.d/" folder in which
we can put namespace directories. This can avoid $namespace name
conflicts with "domain_policy.conf" etc.
I like the "/etc/ccs/policy/$YY-$MM-$DD.$hh:$mm:$ss/kernel/" approach,
but maybe it's better to keep the old layout and retain backwards
compatibility. If we keep the old layout then users can ignore
"/etc/ccs/namespace.d/" directory if they don't need namespace
management.
> If we split /etc/ccs/ files for each namespace, we might also want to split
> corresponding /proc/ccs/ files. Regarding /proc/ccs/ directory:
>
> ...
>
> /proc/ccs/namespace.d/$namespace/
>
> domain_policy Domain policy for $namespace namespace.
> exception_policy Exception policy for $namespace namespace.
> profile Profile for $namespace namespace.
> manager Manager for $namespace namespace.
> .domain_status Subset of domain_policy for /usr/sbin/ccs-setprofile
>
> In this case, $namespace can be any word.
I prefer this approach to avoid name conflicts, and also match
"/etc/ccs/namespace.d/" directory that I proposed above.
_______________________________________________
tomoyo-dev-en mailing list
tomoyo-dev-en@lists.sourceforge.jp
http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev-en
