All of lore.kernel.org
 help / color / mirror / Atom feed
From: Darrel Goeddel <dgoeddel@TrustedCS.com>
To: James Morris <jmorris@redhat.com>
Cc: Stephen Smalley <sds@epoch.ncsc.mil>,
	"selinux@tycho.nsa.gov" <selinux@tycho.nsa.gov>,
	Chad Hanson <chanson@TrustedCS.com>
Subject: Re: [PATCH] devpts xattr support
Date: Wed, 27 Oct 2004 13:10:33 -0500	[thread overview]
Message-ID: <417FE499.3040405@trustedcs.com> (raw)
In-Reply-To: <Xine.LNX.4.44.0410271028050.9447-100000@thoron.boston.redhat.com>

James Morris wrote:
> What other filesystems are likely to need xattr handlers?  It is (now 
> especially) very simple to add them as needed.
> 

All filesystems (and file types) will need that support.  Basically, 
getfilecon should never be unable to retrieve a context for a valid file 
because there actually *is* a context associated with every file, and it 
is being used for access decisions.
Just think if every file had the standard DAC info, but you could only 
see/modify that info on certain filesystems - you may scratch your head 
for a while trying to figure out what is causing access denials.

> I think we should stick with the xattr API, it is "the" way to manage
> extra-inode data under Linux.  Perhaps what we should do instead is fix
> the core xattr code so that it can do what we need it do to.

I'm all for that.  I will play around with a few ideas and see if I can 
come with anything useful.  I'm thinking along the lines of the 
permission call which uses i_op->permission if it exists and falls back 
to vfs_permission if it does not.  Maybe we can create a fallback for 
*xattr...

Thanks everyone for the feedback.

-- 

Darrel Goeddel
Senior Secure Systems Engineer

Trusted Computer Solutions             E: dgoeddel@trustedcs.com
121 West Goose Alley                   V: 217.384.0028 x19
Urbana, IL  61801                      F: 217.384.0288

--
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.

  reply	other threads:[~2004-10-27 18:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-26 14:14 [PATCH] devpts xattr support Darrel Goeddel
2004-10-26 14:42 ` Stephen Smalley
2004-10-26 18:00   ` Darrel Goeddel
2004-10-27 14:15     ` Stephen Smalley
2004-10-27 14:33       ` James Morris
2004-10-27 18:10         ` Darrel Goeddel [this message]
2004-10-27 18:31           ` James Morris
2005-06-13 19:32             ` Stephen Smalley
2005-06-13 21:01               ` Darrel Goeddel
2005-06-14 13:15                 ` Stephen Smalley
2005-06-16 14:45                   ` Darrel Goeddel
2004-10-27 17:18       ` Colin Walters
2004-10-26 18:04   ` Luke Kenneth Casson Leighton

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=417FE499.3040405@trustedcs.com \
    --to=dgoeddel@trustedcs.com \
    --cc=chanson@TrustedCS.com \
    --cc=jmorris@redhat.com \
    --cc=sds@epoch.ncsc.mil \
    --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.