From: sven.vermeulen@siphos.be (Sven Vermeulen)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] [RFC] Introduction of xdg_* types for user content
Date: Tue, 23 Aug 2011 12:22:54 +0200 [thread overview]
Message-ID: <20110823102253.GA628@siphos.be> (raw)
Hi list
While updating my previous domain definition for the mutt e-mail application
(as well as working on a whole lot of other user application domains) I got
more and more into contact with the user-content categorical stuff. We had a
few discussions on it earlier as well, and Dominick also helped me out
investigating all this on #selinux.
In short, user directories have a few locations that are not really /user/
content, but more /user application/ content. This includes of course the
configuration files of user applications, specific data locations and
caches. The freedesktop project [1] has also tried to get these locations
better defined, and created the "XDG Base Directory Specification" [2] from
which I am devising this RFC.
[1] http://www.freedesktop.org/wiki/
[2] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
My initial idea is to support these XDG locations within the SELinux policy,
by creating types such as
- xdg_data_home_t ~/.local/share
- xdg_config_home_t ~/.config
- xdg_cache_home_t ~/.cache
The userdomain definition would then have read/manage interfaces on these
types. Of course, the types themselves are fully manageable by the user
domains themselves.
The advantage of such an approach would be that many domain definitions do
not require userdom_manage_user_home_content_* privileges anymore in the
majority of cases. Also, by destinguishing the types (data, config, cache)
it is also simpler to define the rights. The downside is that quite a few
domains will need to be updated to reflect this, but that shouldn't be a
reason for not doing things ;-)
I do have a couple of questions on this approach though...
1/ Would it be wise to reuse these types?
A prime example: vim, which most likely never needs its own domain, "caches"
information in a ~/.viminfo file. Although this file acts like a cache, it
isn't a file for the XDG specification. Yet I personally mark this file as
xdg_cache_home_t and have all domains that run vim (slrn, mutt) use
userdom_manage_xdg_cache_home().
On one side, I think that is allowed, since the purpose of the type is the
same. But perhaps I shouldn't call the types xdg_* but rather user_*
instead?
2/ Would it be wise to mark HOME_DIR/\.??* as xdg_config_home_t?
Almost all files in a users' home directory that are prepended with a period
are used for configuration purposes. There are exceptions of course, but I
have the impression that these exceptions are managed by their own domains
anyhow. Since HOME_DIR/\.??* is a very generic expression, every module that
defines something with a regular expression "later" than the second position
in the name (say HOME_DIR/\.vnc(/.*)?) will win the file context anyhow.
Wkr,
Sven Vermeulen
next reply other threads:[~2011-08-23 10:22 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-23 10:22 Sven Vermeulen [this message]
2011-08-23 10:56 ` [refpolicy] [RFC] Introduction of xdg_* types for user content Dominick 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=20110823102253.GA628@siphos.be \
--to=sven.vermeulen@siphos.be \
--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.