From: dominick.grift@gmail.com (grift) Date: Tue, 11 Dec 2012 16:00:17 +0100 Subject: [refpolicy] [PATCH 3/3] Implement X Desktop Group In-Reply-To: <50C743AE.30208@tresys.com> References: <1352116515-21046-1-git-send-email-dominick.grift@gmail.com> <1352116515-21046-4-git-send-email-dominick.grift@gmail.com> <1354194543.20999.3.camel@localhost> <50B76876.3010305@tresys.com> <1354198592.20999.5.camel@localhost> <50B8C429.3090901@tresys.com> <1354294882.12168.11.camel@localhost> <50B911B4.4020708@redhat.com> <50C17637.6040801@tresys.com> <1355229303.1797.115.camel@localhost> <50C743AE.30208@tresys.com> Message-ID: <1355238017.1797.118.camel@localhost> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Tue, 2012-12-11 at 09:31 -0500, Christopher J. PeBenito wrote: > On 12/11/2012 7:35 AM, grift wrote: > > On Thu, 2012-12-06 at 23:53 -0500, Christopher J. PeBenito wrote: > >> On 11/30/2012 3:06 PM, Daniel J Walsh wrote: > >>> -----BEGIN PGP SIGNED MESSAGE----- > >>> Hash: SHA1 > >>> > >>> On 11/30/2012 12:01 PM, grift wrote: > >>>> On Fri, 2012-11-30 at 09:35 -0500, Christopher J. PeBenito wrote: > >>>>> On 11/29/12 09:16, grift wrote: > >>>>>> On Thu, 2012-11-29 at 08:51 -0500, Christopher J. PeBenito wrote: > >>>>>>> On 11/29/12 08:09, grift wrote: > >>>>>>>> Are we ready to make a decision yet with regard to the two > >>>>>>>> outstanding issues? > >>>>>>>> > >>>>>>>> - best type names? (my preference user_data_home_t, > >>>>>>>> user_config_home_t, user_cache_home_t) > >>>>>>> > >>>>>>> replace user with xdg, e.g. xdg_config_home_t. > >>>>>>> > >>>>>>>> - should be label ~/.local/share with the xdg data home type or > >>>>>>>> ~/.local ( my preference ~/.local/share) > >>>>>>>> > >>>>>>>> But i will go with whatever in the end > >>>>>>> > >>>>>>> Here's another option to consider: > >>>>>>> > >>>>>>> $HOME/.local -d gen_context(system_u:object_r:xdg_local_home_t,s0) > >>>>>>> $HOME/.local/share(/.*)? > >>>>>>> gen_context(system_u:object_r:xdg_data_home_t,s0) > >>>>>>> > >>>>>>> and then treat xdg_local_home_t similar to user_home_dir_t and > >>>>>>> filetrans everything under it. Then the named filetrans for > >>>>>>> ~/.local/share will work right on top of any of the other random dirs > >>>>>>> that pop up under there. > >>>>>> > >>>>>> I understand your reasoning but i am not confident about the type name > >>>>>> "xdg_local_home_t" and i am also not confident that this type should > >>>>>> be declared in the xserver policy module > >>>>>> > >>>>>> how about we use local_home_t and declare it in the userdomain module? > >>>>> > >>>>> I'm unclear why you disagree. It seems to make sense that 1. this > >>>>> standard is defined by the X desktop group, so xdg doesn't seem so bad to > >>>>> have in the type name. 2. I don't think it makes sense in userdomain > >>>>> because this standard applies to X desktops, so if you don't have an > >>>>> xserver, theres no need for these definitions. > >>>>> > >>>> > >>>> As far as i can see ~/.local is not part of the X desktop group although it > >>>> depends on it for ~/.local/share (data dir) > >>>> > >>>> userdomain might indeed not be a optimal alternative place to declare a > >>>> type for .local but i am not confident that xserver is either. > >>>> > >>>> What i understand is , is that ~/.local is "a place where users can install > >>>> apps with a prefix inside $HOME" > >>>> > >>>> I imagine one could have a headless server without X or the xserver policy > >>>> and still use ~/.local to "install apps with a prefix inside $HOME" > >>>> > >>>> But that is my view and i do not mind going your way. It is not such a big > >>>> deal. > >>>> > >>>> My patch v3 declares xdg_local_home_t is xserver module > >>>> > >>>> > >>> python uses ~/.local > >> > >> Yuck. Well I guess that makes local_home_t make sense for ~/.local and xdg_data_home_t for ~/.local/data. Then local_home_t could be declared in userdomain. > >> > > > > Agreed on the point above > > > > Another different point with regard to the actual XDG types. Would you > > oppose a separate policy module called xdg? > > > > I prefer that over using xserver policy module > > > > My concern is mainly because of the xdg runtime dir. It is not directly > > related to xserver. > > > > If we use a separate policy module for the xdg types then we have a > > little insurance that we do not run into any unneeded dependencies in > > the future. > > I think it depends on the cleanliness of the implementation. Can you do a partial implementation, say implement the support for one of the types? > yes sure i do not see why not (that is if understand you correctly) i will in the near future prepare a patch so that you can see what i have in mind and then you can decide later) better take our time and make the right decision