[tomoyo-dev-en 277] Re: mark PID namespace for delete?

Back to archive index

Horvath Andras han****@log69*****
Fri Jun 10 00:48:22 JST 2011


On Thu, 9 Jun 2011 22:59:57 +0900
Tetsuo Handa <from-****@I-lov*****> wrote:

> Horvath Andras wrote:
> > I see. But can i also write something like:
> > 
> > delete pid=$PID?
> > 
> No.
> 
> > Like mark the domain for delete by PID name? Because i will still
> > need the $domainname, i want to delete only the $PID domain. That
> > will contain rules, that i want the process to have after it
> > restarts.
> > 
> > Is that possible?
> 
> It would be possible to add such command, but I doubt the usefulness
> of such command. Say, there are
> 
>   <kernel> /bin/foo /bin/bar /bin/yourdaemon
>   <kernel> /bin/foo /bin/bar /bin/yourdaemon /bin/sh
>   <kernel> /bin/foo /bin/bar /bin/yourdaemon /bin/sh /bin/cat
> 
> domains and the process is running at
> 
>   <kernel> /bin/foo /bin/bar /bin/yourdaemon
> 
> . In this case, users likely want to delete not only
> 
>   <kernel> /bin/foo /bin/bar /bin/yourdaemon
> 
> domain but also
> 
>   <kernel> /bin/foo /bin/bar /bin/yourdaemon /bin/sh
>   <kernel> /bin/foo /bin/bar /bin/yourdaemon /bin/sh /bin/cat
> 
> domains.
> 
> When deleting a domain, I think users should be aware of
> "What domains are there?".

All in all, i came up with a much simpler idea to apply the same rules
for the running process, and its next domain too. I don't even need the
pid namespace for this.

I list domain_policy and search through all domain names for my domain
where the end of domain name in the current policy matches.

So let's say my domain is (what i want it to belong to later):

<kernel> /usr/sbin/dnsmasq

and the current dnsmasq process is for example in the following domain:

<kernel> /sbin/init /etc/init.d/rc /usr/bin/screen /bin/bash /usr/sbin/dnsmasq

Then i have a match for "/usr/sbin/dnsmasq" at the end, so i load my
rules for the latter domain too. I do the same search for domains with
subdomains too, only checking the matches at the end.




More information about the tomoyo-dev-en mailing list
Back to archive index