From: Chris PeBenito <pebenito@ieee.org>
To: Russell Coker <russell@coker.com.au>,
Topi Miettinen <toiwoton@gmail.com>
Cc: selinux-refpolicy@vger.kernel.org
Subject: Re: systemd_user_runtime_dir_t
Date: Thu, 9 Apr 2020 09:47:54 -0400 [thread overview]
Message-ID: <01acc6a9-8c66-2c64-bfe2-3b44274c366e@ieee.org> (raw)
In-Reply-To: <3285433.FrU4F1G8SV@liv>
On 4/8/20 2:48 AM, Russell Coker wrote:
> On Wednesday, 8 April 2020 4:43:32 PM AEST Topi Miettinen wrote:
>> On 8.4.2020 5.19, Russell Coker wrote:
>>> What kind of name is that? It's a poor choice of name by systemd upstream
>>> and I don't think we are obliged to copy that bad idea.
>>
>> The name is related to environment variable XDG_USER_RUNTIME_DIR, which
>> is not systemd specific construct:
>
> That's a fine name for an environment variable, clearly indicating that it
> points to a directory.
>
> It's a poor name for a domain, making a casual observer think it's a type for
> a directory not a domain for a process.
>
>> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
>>
>> So if the name should change, xdg_user_runtime_dir_t might be more
>> accurate.
>
> It would be more accurate to have a name that reflects the function of managing
> the directory in question.
>
>> On the other hand, the current name reflects that it's
>> specifically the service supplied by systemd called
>> "runtime-user-dir@.service" which provides the directory. If the
>> provider would be something other (/etc/init.d/elogind-mkuserdir), it
>> could be equally accurate to label the directory with something else.
>
> If the provider changed to a different process (theoretically we are supposed
> to be able to swap out parts of systemd for equivalents) then it should have
> the same domain name.
>
>> Though if the result (temporary directory owned by the user) is no
>> different in either case from the point of view of SELinux policy, why
>> change?
>
> SE Linux is difficult enough to understand without making things needlessly
> confusing.
You're right. I wasn't pleased when I came across it. However, the way I see
it, the direction you suggest is confusing in a different way, since it doesn't
obviously align with the systemd command name. I see it as being between a rock
and a hard place, so I'm inclined to keep it as-is. This isn't a domain that is
going to show up all over the place, it is a microscopic niche of the byzantine
set of processes under the systemd umbrella.
--
Chris PeBenito
prev parent reply other threads:[~2020-04-09 13:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-08 2:19 systemd_user_runtime_dir_t Russell Coker
2020-04-08 6:43 ` systemd_user_runtime_dir_t Topi Miettinen
2020-04-08 6:48 ` systemd_user_runtime_dir_t Russell Coker
2020-04-09 13:47 ` Chris PeBenito [this message]
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=01acc6a9-8c66-2c64-bfe2-3b44274c366e@ieee.org \
--to=pebenito@ieee.org \
--cc=russell@coker.com.au \
--cc=selinux-refpolicy@vger.kernel.org \
--cc=toiwoton@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).