From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from jazzhorn.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with SMTP id l27E0Jqc017869 for ; Wed, 7 Mar 2007 09:00:19 -0500 Received: from nz-out-0506.google.com (jazzhorn.ncsc.mil [144.51.5.9]) by jazzhorn.ncsc.mil (8.12.10/8.12.10) with ESMTP id l27E1iPG023792 for ; Wed, 7 Mar 2007 14:01:45 GMT Received: by nz-out-0506.google.com with SMTP id z3so123235nzf for ; Wed, 07 Mar 2007 06:01:44 -0800 (PST) Message-ID: <45EEC5BF.9020305@kaigai.gr.jp> Date: Wed, 07 Mar 2007 23:01:35 +0900 From: KaiGai Kohei MIME-Version: 1.0 To: russell@coker.com.au CC: Stephen Smalley , selinux@tycho.nsa.gov Subject: Re: [ANN] SE-PostgreSQL 8.2.3-1.0 alpha release References: <45EC0D21.2070706@kaigai.gr.jp> <45EDBB95.50703@kaigai.gr.jp> <1173208625.1230.6.camel@moss-spartans.epoch.ncsc.mil> <200703070936.04240.russell@coker.com.au> In-Reply-To: <200703070936.04240.russell@coker.com.au> Content-Type: text/plain; charset=UTF-8; format=flowed Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov Russell Coker wrote: > On Wednesday 07 March 2007 06:17, Stephen Smalley wrote: >>> We have to store a security context of tuple in anywhere, so modifying >>> the file format was not avoidable. The storage manager of PostgreSQL >>> cannot handle different file formats, so SE-PostgreSQL cannot run over >>> the unlabeled databased generated by native PostgreSQL. >>> >>> It might be possible, but I expect more hooks to the PostgreSQL is >>> necessary. It will prevent to follow the version-up of native one. >> Do they provide any kind of attribute / metadata support at that >> granularity? Along the lines of filesystem xattrs? >> >> Could you store the labels in a separate table? Along the lines of the >> old persistent label mapping in SELinux (issues for consistency and >> performance, of course). > > The labelling for tables and columns could be stored in a different table as > they don't change much. > > The labelling of rows could be stored in an extra column in the table. > > Then if the non-SE version of PostgreSQL had some code to ignore the SE Linux > column then we would have fairly good compatibility. > > Kohei-san, is this a viable idea? Russell, Actually, I tried to use an extra (hidden) column to store a security context, but gave up this approach. # The following branch is the one just before I gave up: # http://sepgsql.googlecode.com/svn/branches/sepgsql_070210/ It did not resolve file format issue, because we have to add an extra column into system catalog to associate a security context with table, column and so on. (*) system catalog is a table to store the meta-information like the definition of the table. The definition of system catalogs are hard-coded in the header files, so adding an extra column could not avoid to break the database file format compatibility.... Thanks, -- KaiGai Kohei -- 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.