From: Daniel J Walsh <dwalsh@redhat.com>
To: SELinux <selinux@tycho.nsa.gov>
Subject: Changing unlabeled_t on files to invalid_label_t.
Date: Thu, 09 Jan 2014 16:53:23 -0500 [thread overview]
Message-ID: <52CF1A53.9080501@redhat.com> (raw)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
We would like to change
sid file_labels gen_context(system_u:object_r:unlabeled_t,s0)
to something like
sid file_labels gen_context(system_u:object_r:invalid_label_t,s0)
Since explaining to someone that a file without a label is file_t, but if it
has a label that the kernel does not understand it is labeled as unlabeled_t.
A file with a label is unlabeled_t???? While a file without a label is file_t.
#
# unlabeled_t is the type of unlabeled objects.
# Objects that have no known labeling information or that
# have labels that are no longer valid are treated as having this type.
#
#
# file_t is the default type of a file that has not yet been
# assigned an extended attribute (EA) value (when using a filesystem
# that supports EAs).
#
These two type definitions seem to conflict, with file_t winning at least on
systems that support XAttrs.
I would guess a better fix would be to change the kernel to handle the case
where an object is unlabeled_t one way and if it is labeled and the kernel
does not understand the label differently.
sid invalid_file_labels gen_context(system_u:object_r:invalid_label_t,s0)
Opinions....
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlLPGlMACgkQrlYvE4MpobOrDwCgwSduQpyqjGFni/0dksiv0I2j
uEAAn181YTHYYRj0XSern/+CPtuUp7Vu
=3HJ3
-----END PGP SIGNATURE-----
next reply other threads:[~2014-01-09 21:53 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-09 21:53 Daniel J Walsh [this message]
2014-01-09 22:21 ` Changing unlabeled_t on files to invalid_label_t Dominick Grift
2014-01-09 22:49 ` Dominick Grift
2014-01-10 0:26 ` Paul Moore
2014-01-09 22:54 ` Paul Moore
2014-01-09 23:07 ` Eric Paris
2014-01-09 23:22 ` Dominick Grift
2014-01-10 0:23 ` Paul Moore
2014-01-10 11:52 ` Dominick Grift
2014-01-10 14:42 ` Paul Moore
2014-01-10 14:42 ` Stephen Smalley
2014-01-10 14:49 ` Paul Moore
2014-01-10 14:56 ` Stephen Smalley
2014-01-10 16:13 ` Stephen Smalley
2014-01-10 16:23 ` Paul Moore
2014-01-12 1:37 ` Russell Coker
2014-01-09 22:23 ` Ted Toth
2014-01-09 22:45 ` Paul Moore
2014-01-10 16:06 ` Stephen Smalley
2014-01-10 16:13 ` Daniel J Walsh
2014-01-10 16:14 ` Stephen Smalley
2014-01-13 20:07 ` Christopher J. PeBenito
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=52CF1A53.9080501@redhat.com \
--to=dwalsh@redhat.com \
--cc=selinux@tycho.nsa.gov \
/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.