Re: object class discovery userland

[KaiGai Kohei <kaigai@kaigai.gr.jp>]

> I think that because of the heavy customization in the Postgres AVC 
> implementation it is best kept outside-of-tree at the current time.

OK,

> There are other applications that use process pools such as Apache and 
> if these become hosts to object managers then it may be useful to 
> provide a shared memory option in the libselinux version.  The solution 
> would involve a flag to the init function, some method of providing the 
> shared memory segment to attach to, and special functionality for the 
> "manager" process that will listen on netlink.

Can I consider those features as a future todo? Or, do you want to have
a discussion in this chance?

> However, the Postgres implementation is not fully "shared memory" based. 
>  The SID-to-context mapping is kept in a "pg_selinux" database table 
> which is not stored in shared memory but rather is mapped from disk 
> (correct me if I'm wrong). 

It's correct. SE-PostgreSQL leverages one of the subsystems provided by native
PostgreSQL, to implement SID-to-context mapping. It is not based on share memory
directly.

> In the previous thread, the possibility of 
> providing callbacks for doing the SID-to-context mapping was discussed. 
>  However IMO if this part of the library has to be outsourced to the 
> application then the application might as well do the entire AVC.

I agrees your opinion.
In the case that applications can handle SID-to-context mapping well,
those works should be outsourced and being detachable from libselinux's AVC.

In my case, an idea using PostgreSQL's Oid (Object Identifier) as a persistent
SID works well :)

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.