On Fri, Dec 12, 2008 at 11:57 AM, Gregory Stark <stark@enterprisedb.com> wrote:
>> Obviously sandwhiching two values in one column is not going to work.
>> The only question here is whether it's important to simultaneously
>> support both DAC and MAC. As far as I can see, KaiGai is the only one
>> arguing that we don't need to do that (except for Tom, who doesn't
>> like either feature). If anyone else agrees with his position, now
>> would be a good time to speak up.
>
> Well maybe I'm not following. I think it's strange to need two different
> row-based security methods. Can you give some examples of how you would use
> these two mechanisms together?
Not really. I'm not an SELinux expert. But typically the two do
exist alongside one another. For example, installing SELinux (MAC)
does on your system does not make "chmod g+w file" (DAC) stop working;
it merely performs an ADDITIONAL security check before allowing access
to the file. You have to satisfy BOTH SELinux AND the ordinary
filesystem permissions system in order to perform an operation on a
file.
Similarly, we have SQL statements "GRANT {SELECT|INSERT|DELETE|etc} ON
table..." and hopefully soon a column-level variant of that same
syntax. Those permissions aren't going to be ignored just because you
also enable SELinux to control access to those tables or columns. Or
at least I certainly hope they aren't.
The contention of the author of this patch is that row-level access is
somehow different - that even though we have two sets of checks for
files, tables, and (assuming Stephen Frost's patch is accepted)
columns, we will only have one set of checks for rows, and you can
pick which one you want.
...Robert