Introduce xdg types

PATCH Superseded Sven Vermeulen 2 participants 7 messages Oct 13, 2011 – May 10, 2012

Share & tools

Sven Vermeulen

author

2011-10-13 14:06 UTC #0 lore raw

PATCH v3 1/1 Introduce xdg types

With some delay (busy days at work), the XDG module with the feedback from Dominick integrated. Changes since v2 include

- Rename of interfaces to be more in lign with naming conventions
- Use of userdom_search_... instead of userdom_list_...
- Add the lnk_file and fifo_file classes in the xdg_manage_* interfaces
- Drop the xdg_admin interface
- Add a few TODOs that need to be written when named file transitions are supported (didn't want to include it as comments since M4 doesn't like that)

Wkr,
Sven Vermeulen

+++

The XDG Base Directory specification is an open specification for dealing with user data in a desktop environment. It is published on
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
and in use by many applications.

In this patch, we introduce the xdg-specific types and give the standard interfaces for dealing with these types. We also provide a typeattribute for each of the xdg-specific locations, allowing applications that create files therein to mark these files as the appropriate xdg type.

Signed-off-by Sven Vermeulen <[email protected]>

---
 xdg.fc |    8 +
 xdg.if |  577 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 xdg.te |   26 +++
 3 files changed, 611 insertions(+), 0 deletions(-)
 create mode 100644 xdg.fc
 create mode 100644 xdg.if
 create mode 100644 xdg.te

xdg.fc new file +8 -0

new file mode 100644
index 0000000..49a52d9
@@ -0,0 +1,8 @@
+HOME_DIR/\.cache(/.*)?		gen_context(system_u:object_r:xdg_cache_home_t,s0)
+HOME_DIR/\.config(/.*)?		gen_context(system_u:object_r:xdg_config_home_t,s0)
+HOME_DIR/\.local(/.*)?		gen_context(system_u:object_r:xdg_data_home_t,s0)
+
+#
+# /run
+#
+/run/user/USER(/.*)?			gen_context(system_u:object_r:xdg_runtime_home_t,s0)

xdg.if new file +577 -0

577 lines not on this page · raw message

xdg.te new file +26 -0

new file mode 100644
index 0000000..f9088b4
@@ -0,0 +1,26 @@
+policy_module(xdg, 1.0.0)
+
+########################################
+#
+# Declarations
+#
+
+attribute xdg_data_home_type;
+
+attribute xdg_config_home_type;
+
+attribute xdg_cache_home_type;
+
+attribute xdg_runtime_home_type;
+
+type xdg_data_home_t;
+xdg_data_home_content(xdg_data_home_t)
+
+type xdg_config_home_t;
+xdg_config_home_content(xdg_config_home_t)
+
+type xdg_cache_home_t;
+xdg_cache_home_content(xdg_cache_home_t)
+
+type xdg_runtime_home_t;
+xdg_runtime_home_content(xdg_runtime_home_t)

Signature · 1 line

1.7.3.4

Sven Vermeulen

author

2011-11-13 20:33 UTC #1 lore raw

PATCH v3 1/1 Introduce xdg types

Quoted 10 lines · Sven Vermeulen

With some delay (busy days at work), the XDG module with the feedback from Dominick integrated. Changes since v2 include
- Rename of interfaces to be more in lign with naming conventions
- Use of userdom_search_... instead of userdom_list_...
- Add the lnk_file and fifo_file classes in the xdg_manage_* interfaces
- Drop the xdg_admin interface
- Add a few TODOs that need to be written when named file transitions are supported (didn't want to include it as comments since M4 doesn't like that)

Now that named file transitions are supported [1], I'd like to add a rule that, when a one of the following directories is created, that directory is immediately labeled appropriately:

- ~/.cache -> xdg_cache_home_t
- ~/.config -> xdg_config_home_t
- ~/.local -> xdg_data_home_t

To do so, I thought about doing this in the following steps:

(1.) Enhance userdom_user_home_dir_filetrans with a fourth argument
(filename) and use that in its filetrans_pattern() call
(2.) Enhance xdg.if with the xdg_*_home_filetrans statements that accomplish
something like
userdom_user_home_dir_filetrans($1, xdg_cache_home_t, dir, ".cache")
for the xdg_cache_home_filetrans (others very related)
(3.) Enhance application.te with optional calls like
"xdg_cache_home_filetrans(application_domain_type)"

Is this a proper way to handle the above? Is application_domain_type the right level?

Wkr,
Sven Vermeulen

[1] http://oss.tresys.com/pipermail/refpolicy-commits/2011-November/000029.html

Christopher J. PeBenito

2011-11-14 20:35 UTC #2 lore raw

PATCH v3 1/1 Introduce xdg types

Quoted 20 lines · Sven Vermeulen

Quoted 10 lines · Sven Vermeulen
With some delay (busy days at work), the XDG module with the feedback from Dominick integrated. Changes since v2 include
- Rename of interfaces to be more in lign with naming conventions
- Use of userdom_search_... instead of userdom_list_...
- Add the lnk_file and fifo_file classes in the xdg_manage_* interfaces
- Drop the xdg_admin interface
- Add a few TODOs that need to be written when named file transitions are supported (didn't want to include it as comments since M4 doesn't like that)
Now that named file transitions are supported [1], I'd like to add a rule that, when a one of the following directories is created, that directory is immediately labeled appropriately:
- ~/.cache -> xdg_cache_home_t
- ~/.config -> xdg_config_home_t
- ~/.local -> xdg_data_home_t

Quoted 8 lines

To do so, I thought about doing this in the following steps:
(1.) Enhance userdom_user_home_dir_filetrans with a fourth argument
(filename) and use that in its filetrans_pattern() call
(2.) Enhance xdg.if with the xdg_*_home_filetrans statements that accomplish
something like
userdom_user_home_dir_filetrans($1, xdg_cache_home_t, dir, ".cache")
for the xdg_cache_home_filetrans (others very related)

These two are fine. I've attached my working patch for interfaces with optional parameters to support name filetrans. I'm trying to decide (with CIL in mind) if we really want interfaces with optional parameters.

Quoted 5 lines

(3.) Enhance application.te with optional calls like
"xdg_cache_home_filetrans(application_domain_type)"
Is this a proper way to handle the above? Is application_domain_type the right level?

I would say no. The application module is for all applications, not just X ones. Possibly in the xserver_user_x_domain_template() it would make more sense.

Quoted 1 line

[1] http://oss.tresys.com/pipermail/refpolicy-commits/2011-November/000029.html

Signature · 7 lines

Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: name_filetrans.diff
Url: http://oss.tresys.com/pipermail/refpolicy/attachments/20111114/caedee6b/attachment.pl

Sven Vermeulen

author

2011-11-15 07:33 UTC #3 lore raw

PATCH v3 1/1 Introduce xdg types

Quoted 10 lines · Christopher J. PeBenito

Quoted 6 lines
(1.) Enhance userdom_user_home_dir_filetrans with a fourth argument
(filename) and use that in its filetrans_pattern() call
(2.) Enhance xdg.if with the xdg_*_home_filetrans statements that accomplish
something like
userdom_user_home_dir_filetrans($1, xdg_cache_home_t, dir, ".cache")
for the xdg_cache_home_filetrans (others very related)
These two are fine. I've attached my working patch for interfaces with optional parameters to support name filetrans. I'm trying to decide (with CIL in mind) if we really want interfaces with optional parameters.

As opposed to different interface names? Like using a _named_filetrans:
userdom_user_home_dir_filetrans versus userdom_user_home_dir_named_filetrans (just a hypothetical example) ?

I'm okay with either. If you were to allow optional parameters, you probably will end up with at most one optional parameter (if you have two, how would you allow having the second one set but not the first).

Wkr,
Sven Vermeulen

Christopher J. PeBenito

2011-11-15 14:23 UTC #4 lore raw

PATCH v3 1/1 Introduce xdg types

Quoted 8 lines · Sven Vermeulen

Quoted 7 lines · Christopher J. PeBenito
Quoted 6 lines
(1.) Enhance userdom_user_home_dir_filetrans with a fourth argument
(filename) and use that in its filetrans_pattern() call
(2.) Enhance xdg.if with the xdg_*_home_filetrans statements that accomplish
something like
userdom_user_home_dir_filetrans($1, xdg_cache_home_t, dir, ".cache")
for the xdg_cache_home_filetrans (others very related)

Quoted 7 lines

Quoted 3 lines
These two are fine. I've attached my working patch for interfaces with optional parameters to support name filetrans. I'm trying to decide (with CIL in mind) if we really want interfaces with optional parameters.
As opposed to different interface names? Like using a _named_filetrans:
userdom_user_home_dir_filetrans versus userdom_user_home_dir_named_filetrans (just a hypothetical example) ?

Yes.

Quoted 3 lines

I'm okay with either. If you were to allow optional parameters, you probably will end up with at most one optional parameter (if you have two, how would you allow having the second one set but not the first).

I don't have a compelling argument either way. I suspect that if we did go the optional parameter route, the refpolicy->CIL compiler would have to convert optional parameter interfaces into to two CIL macros with different names anyway.

Signature · 3 lines

Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

Sven Vermeulen

author

2012-05-01 07:31 UTC #5 lore raw

PATCH v3 1/1 Introduce xdg types

In reply to Christopher J. PeBenito

Quoted 10 lines · Christopher J. PeBenito

Quoted 6 lines
(1.) Enhance userdom_user_home_dir_filetrans with a fourth argument
(filename) and use that in its filetrans_pattern() call
(2.) Enhance xdg.if with the xdg_*_home_filetrans statements that accomplish
something like
userdom_user_home_dir_filetrans($1, xdg_cache_home_t, dir, ".cache")
for the xdg_cache_home_filetrans (others very related)
These two are fine. I've attached my working patch for interfaces with optional parameters to support name filetrans. I'm trying to decide (with CIL in mind) if we really want interfaces with optional parameters.

Got your mind settled yet?

I noticed that the filetrans_pattern() definition supports the fifth argument (as an optional parameter). Is it okay if we apply your patch (except for the filetrans_pattern() part) and continue from there?

Wkr,
Sven Vermeulen

Christopher J. PeBenito

2012-05-10 13:57 UTC #6 lore raw

PATCH v3 1/1 Introduce xdg types

Quoted 12 lines · Sven Vermeulen

Quoted 10 lines · Christopher J. PeBenito
Quoted 6 lines
(1.) Enhance userdom_user_home_dir_filetrans with a fourth argument
(filename) and use that in its filetrans_pattern() call
(2.) Enhance xdg.if with the xdg_*_home_filetrans statements that accomplish
something like
userdom_user_home_dir_filetrans($1, xdg_cache_home_t, dir, ".cache")
for the xdg_cache_home_filetrans (others very related)
These two are fine. I've attached my working patch for interfaces with optional parameters to support name filetrans. I'm trying to decide (with CIL in mind) if we really want interfaces with optional parameters.

Quoted 5 lines

Got your mind settled yet?
I noticed that the filetrans_pattern() definition supports the fifth argument (as an optional parameter). Is it okay if we apply your patch (except for the filetrans_pattern() part) and continue from there?

Yes. I merged it.

Signature · 3 lines

Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com