From: Daniel J Walsh <dwalsh@redhat.com>
To: Colin Walters <walters@verbum.org>
Cc: "Christopher J. PeBenito" <cpebenito@tresys.com>,
Joshua Brindle <method@gentoo.org>,
Russell Coker <russell@coker.com.au>,
SELinux Mail List <selinux@tycho.nsa.gov>
Subject: Re: [RFC] Upstream policy handling
Date: Thu, 23 Sep 2004 12:43:12 -0400 [thread overview]
Message-ID: <4152FD20.4020302@redhat.com> (raw)
In-Reply-To: <1095695627.4431.157.camel@nexus.verbum.private>
Colin Walters wrote:
>On Mon, 2004-09-20 at 08:56 -0400, Christopher J. PeBenito wrote:
>
>
>
>>And my response was that it was not a clean way to do it imo. I think
>>sysadmfile is an overused attribute. You're suggesting adding another
>>attribute to fix an attribute problem. The way I did it was to reduce
>>the sysadmfile types, and then add a tunable that gives back full access
>>if needed by using { file_type -shadow_t }, which is basically what
>>sysadmfile is currently. If there are other references to sysadmfile,
>>they can also be replaced with the above set. I don't see how this is
>>less mergeable.
>>
>>
>
>I'd need to see your patch, but if sysadmfile is really as close to
>{ file_type -shadow_t } as you say, then that sounds fine too.
>
>
>
With russells latest patches sysadmfile is the same as file_type
-shadow_t , so we should be able to have a
tunable to restrict sysadm_r access to sysadmfile.
>
>--
>This message was distributed to subscribers of the selinux mailing list.
>If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
>the words "unsubscribe selinux" without quotes as the message.
>
>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
next prev parent reply other threads:[~2004-09-23 16:43 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-19 15:07 [RFC] Upstream policy handling Joshua Brindle
2004-09-19 19:21 ` Luke Kenneth Casson Leighton
2004-09-19 21:10 ` Luke Kenneth Casson Leighton
2004-09-19 20:46 ` Russell Coker
2004-09-19 21:11 ` Joshua Brindle
2004-09-19 21:29 ` Russell Coker
2004-09-19 23:48 ` Joshua Brindle
2004-09-20 3:33 ` Colin Walters
2004-09-20 12:26 ` Daniel J Walsh
2004-09-20 12:56 ` Christopher J. PeBenito
2004-09-20 15:53 ` Colin Walters
2004-09-20 20:44 ` File types that are not sysadmfiles Daniel J Walsh
2004-09-21 5:08 ` Russell Coker
2004-09-21 14:42 ` Colin Walters
2004-09-21 15:25 ` Russell Coker
2004-09-21 15:45 ` Colin Walters
2004-09-21 14:42 ` Colin Walters
2004-09-22 20:22 ` James Carter
2004-09-23 16:43 ` Daniel J Walsh [this message]
2004-09-23 19:10 ` [RFC] Upstream policy handling Russell Coker
2004-09-20 12:25 ` Luke Kenneth Casson Leighton
2004-09-20 14:54 ` Russell Coker
2004-09-19 22:08 ` Colin Walters
2004-09-19 23:24 ` Joshua Brindle
2004-09-20 0:07 ` Colin Walters
2004-09-20 12:22 ` Luke Kenneth Casson Leighton
2004-09-20 15:17 ` Thomas Bleher
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=4152FD20.4020302@redhat.com \
--to=dwalsh@redhat.com \
--cc=cpebenito@tresys.com \
--cc=method@gentoo.org \
--cc=russell@coker.com.au \
--cc=selinux@tycho.nsa.gov \
--cc=walters@verbum.org \
/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.