Christopher J. PeBenito wrote: > (sorry for the dupe KaiGai, but I got a delivery failure on the nsa addresses) I have not got this message via nsa list. :-( > On Mon, 2008-05-12 at 23:33 +0900, KaiGai Kohei wrote: >>>> type_transition postgresql_t postgresql_t:db_database sepgsql_db_t; >>>> >>>> What object is being transitioned on? Other type transitions are >>>> clearer: a file being created in a directory or a message enqueued to a >>>> message queue. I won't block merging the policy over this, but I think >>>> the postgresql_contexts is the better method. >>> This type transition rule means a new database is created on a database >>> management system. A database management system can maintain several >>> databases in same time, like several files are placed under a directory. >>> An only difference between a directory and a database management system >>> is whether it is a process, or not. So, I don't think it is unnatural >>> method to decide a correct context of newly created database. >> In properly speaking, I oppose to drop type_transition rule for a newly >> created database object, don't oppose the postgresql_contexts file. >> I noticed they are not exclusive options after a carefull consideration. >> >> The biggest concern of dropping type_transition is that we cannot decide >> what security context should be attached for a new database when >> the postgresql_contexts is lost, if we completely depends on this file. >> We can help the situation, if we can decide it with type_transition rule >> when the file or proper entries are not found. > > I'd say its not unreasonable to require that postgresql_contexts exists. > If it doesn't, it could just create the databases unlabeled, or the > services fails to start when its missing. I don't know which is the > better answer, so I'll reference another object manager. Eamon, what do > you do in the X server when the x_contexts file is incomplete or > missing? Hmm... Because the policy does not allow to create a database with unlabeled_t, I will choose the later option (failing services when starting up). Is it possible to add a new initial security context to provide a fallback context of newly created databases as an alternative of "unlabeled"? It will be better, if we can got a proper context when the postgresql_context is missing. >> If you feel strange to use the context of server process as the target >> of the type_transition, using the root directory of database cluster >> is an alternative idea. (It is '/var/lib/sepgsql/data' in default.) >> Any database files are placed under the directory, like filed placed >> under a directory. > > I think that this is much less desirable option than what we have right > now. Database objects don't exist outside of postgresql since its a > userspace object manager. The fact that they're stored as files in a > directory isn't relevant from the database object's perspective. OK, please forget this idea. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@xxxxxxxxxxxxx> -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
