From: cpebenito@tresys.com (Christopher J. PeBenito)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] [PATCH 3/3] Implement X Desktop Group
Date: Mon, 26 Nov 2012 11:35:23 -0500 [thread overview]
Message-ID: <50B39A4B.6000905@tresys.com> (raw)
In-Reply-To: <1352116515-21046-4-git-send-email-dominick.grift@gmail.com>
Overall, I'm ok with this, but have a couple questions:
On 11/05/12 06:55, Dominick Grift wrote:
> Creates 3 type attributes for xdg cache (~/.cache), config (~/.config)
> and data (~/.local/share user home content and assigns to
> xserver_user_cache_home_content(), xserver_user_config_home_content()
> and xserver_user_data_home_content() respectively
>
> Creates 3 types for generic xdg user cache, config and data home
> content, assigns to them their respective type attributes and
> classifieds them user_home_content_type by calling xserver_user_cache,
> config, data_home_content
>
> Create the various basic interfaces that will be needed:
>
> 1. xserver_create_generic_user_cache, config, data, home_dirs:
> This will be used together with
> xserver_user_home_(content|dir)_filetrans_cache, config,
> data_home_content and allows the caller to create ~/.cache, ~/.config
> and ~/.local/share directories. Each XDG aware program needs to be
> able to create these.
>
> 2. xserver_read|manage_generic_user_cache, config, data_home_content:
> By default content is created with a generic type and these broad
> interfaces allow the caller to read of manage content with these
> generic types
>
> 3. xserver_user_cache, config, data_home_content_filetrans:
> Allows callers to create specified objects in these location with a
> private type
>
> Add file context specifications for ~/.cache(/.*)? (user_cache_home_t),
> ~/.config(/.*)? (user_config_home_t) and ~/.local/share(/.*)?
> (user_data_home_t)
I'm not sure that user_data_home_t is the best name. I thought about user_local_home_t, but thats vague too. Sven has been putting forward a patch for this stuff for a while too, and I'm thinking the it might make sense to have xdg in the type names.
> There is a little issue with user_data_home, this is content for
> ~/.local/share and as per xdg specification "share" is the user data
> root dir instead of ~/.local, that means that the type transition
> happens on user home content instead of user home dir. this makes it a
> bit more prone to error since all directories named share created by
> xserver_restricted_role callers in generic user home content
> directories will be created with user_data_home_t. We could consider
> using ~/.local instead
It seems that .local would probably be a better idea, since it keeps errors down. I looked on my system, and all I have in ~/.local is share anyway.
[cut]
> diff --git a/policy/modules/services/xserver.te b/policy/modules/services/xserver.te
> index 9bc86a0..a42f9bc 100644
> --- a/policy/modules/services/xserver.te
> +++ b/policy/modules/services/xserver.te
> @@ -49,6 +49,11 @@ gen_tunable(xserver_object_manager, false)
>
> attribute x_domain;
>
> +# X Desktop Group
> +attribute xserver_user_cache_home_content_type;
> +attribute xserver_user_config_home_content_type;
> +attribute xserver_user_data_home_content_type;
> +
> # X Events
> attribute xevent_type;
> attribute input_xevent_type;
I'm unclear what the purpose of these attributes will be. Do you expect to have interfaces that work on these?
I've merged the other two patches.
--
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com
next prev parent reply other threads:[~2012-11-26 16:35 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-05 11:55 [refpolicy] [PATCH 0/3] Implement X Desktop Group and relevant dependencies Dominick Grift
2012-11-05 11:55 ` [refpolicy] [PATCH 1/3] Create a attribute user_home_content_type and assign it to all types that are classified userdom_user_home_content() Dominick Grift
2012-11-05 11:55 ` [refpolicy] [PATCH 2/3] These two attribute are unused Dominick Grift
2012-11-05 11:55 ` [refpolicy] [PATCH 3/3] Implement X Desktop Group Dominick Grift
2012-11-26 16:35 ` Christopher J. PeBenito [this message]
[not found] ` <1353950589.10744.5.camel@x220.mydomain.internal>
[not found] ` <50B4BDE4.4080703@tresys.com>
2012-11-27 13:27 ` Dominick Grift
2012-11-27 15:31 ` Sven Vermeulen
2012-11-29 13:09 ` grift
2012-11-29 13:51 ` Christopher J. PeBenito
2012-11-29 14:16 ` grift
2012-11-29 14:48 ` grift
2012-11-30 14:35 ` Christopher J. PeBenito
2012-11-30 17:01 ` grift
2012-11-30 20:06 ` Daniel J Walsh
2012-12-07 4:53 ` Christopher J. PeBenito
2012-12-11 12:35 ` grift
2012-12-11 14:31 ` Christopher J. PeBenito
2012-12-11 15:00 ` grift
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50B39A4B.6000905@tresys.com \
--to=cpebenito@tresys.com \
--cc=refpolicy@oss.tresys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.