All of lore.kernel.org
 help / color / mirror / Atom feed
From: Serge Hallyn <serge.hallyn@gmail.com>
To: Stephen Smalley <sds@epoch.ncsc.mil>
Cc: selinux@tycho.nsa.gov
Subject: Re: learning about policies/transitions
Date: Thu, 4 Nov 2004 20:23:00 -0600	[thread overview]
Message-ID: <46ce702f041104182352cbcd1@mail.gmail.com> (raw)
In-Reply-To: <1099588265.3174.158.camel@moss-spartans.epoch.ncsc.mil>

Addendum:  running setfilecon works once.  After each reboot, I must again run
setfilecon.before /bin/login will cause the transition to login_d. 
Again, running
/bin/ls -Z /bin/login shows no difference before and after the
setifilecon - it is always
of type login_et.

At this point, I suppose I should just switch to the latest fedora deverlopment
release and see whether this problem magically resolves itself.  If
not, I guess some
debug info at d_instantiate will be order.

thanks,
-serge

On Thu, 04 Nov 2004 12:11:06 -0500, Stephen Smalley <sds@epoch.ncsc.mil> wrote:
> On Thu, 2004-11-04 at 11:20, Serge Hallyn wrote:
> > Ah, running setfilecon worked.
> >
> > I don't understand why, though.  The security.selinux xattr (as given by
> > getxattr(2)) looked the same before and after.  What else is being changed
> > by setfilecon?
> 
> The incore inode SID.  setfilecon(1) unconditionally calls
> setfilecon(3), which invokes setxattr(2), which will invoke the
> post_setxattr hook and update the incore inode SID.  setfiles and/or
> chcon would have just looked at the existing on-disk xattr value (via
> getfilecon(3)->getxattr(2)), seen that the on-disk xattr was already
> correct, and not bothered to call setfilecon(3), so the incore inode SID
> wasn't being updated by those programs.  I think RedHat is/has added an
> option to chcon(1) to force the call to setfilecon(3) regardless of its
> current value.  Perhaps setfiles(1) should unconditionally call
> setfilecon(3) too.
> 
> This is an unfortunate side effect of using the xattr API (vs. the
> original SELinux API, which directly fetched the incore inode SID and
> returned it to the caller), because the xattr API always consults the
> filesystem and reports the on-disk xattr.  SELinux maps the on-disk
> xattr to a SID at the time of d_instantiate, but if the on-disk xattr is
> invalid at that time (e.g. type isn't defined in the policy), then the
> inode SID is left unlabeled and it requires an explicit setxattr(2) to
> correct.
> 
> --
> 
> 
> Stephen Smalley <sds@epoch.ncsc.mil>
> National Security Agency
> 
>

--
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-11-05  2:23 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-03 16:45 learning about policies/transitions Serge Hallyn
2004-11-03 19:29 ` Stephen Smalley
2004-11-04 16:20   ` Serge Hallyn
2004-11-04 17:11     ` Stephen Smalley
2004-11-05  2:23       ` Serge Hallyn [this message]
2004-11-05 12:26         ` Stephen Smalley
2004-11-15 16:12           ` Serge Hallyn
2004-11-15 16:38             ` Stephen Smalley
2004-11-15 17:07               ` Serge Hallyn
2004-11-15 17:28                 ` Stephen Smalley
2004-11-15 18:03                   ` Serge Hallyn
2004-11-23  4:21             ` Russell Coker

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=46ce702f041104182352cbcd1@mail.gmail.com \
    --to=serge.hallyn@gmail.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.