All of lore.kernel.org
 help / color / mirror / Atom feed
From: Forrest Whitcher <fw@fwsystems.com>
To: Stephen Smalley <sds@tislabs.com>, SE Linux list <selinux@tycho.nsa.gov>
Subject: selinux and AFS
Date: Wed, 08 Aug 2001 13:56:24 -0400	[thread overview]
Message-ID: <3B717D48.C76441D5@fwsystems.com> (raw)
In-Reply-To: Pine.SOL.3.95.1010723090133.3466D-100000@clipper.gw.tislabs.com


Stephen et al.

I imagine you've had enough 'progress' reports from me, however
I *think* I have figured out the cause of the failure in getting
openAFS to run under the selinux kernel (2.2.19).

Diagnostics on attempting mount were:

>From afsd:
--afsd: Mounting the AFS root on '/afs', flags: 0.
--afsd: Can't mount AFS on /afs(22)

>From the kernel:
--security_compute_av:  unrecognized SID 0
--psid_release:  uninitialized super block

I traced the return call error (EINVAL) to two places. 

First in super.c lines 973, 981 - psid_release when afs attempts 
the mount.

Second in security/services.c at lines 727, 278 - security_compute_av.

I then modified the former to never return an error code, thus 
allowing the mount to proceed. At this point, every attempt to
touch an object at or below the /afs root results in a repetition
of the last diagnostic

--security_compute_av:  unrecognized SID 0

(in these instances it is failing on the 'tsid' lookup- services.c l 278;
in the mount attempt it is the ssid lookup - services.c l 272)

obviously I can  'echo /*' and see that the afs dir is there, however
the above error is returned by any attempt to actually read data
from the filesystem (ls || stat || ...)

Although I have not had time to further trace into the kernel 
sources (spent some time digging, but other things came up)..

I believe I have a good guess about what's causing the problem.

AFS identifies the inode of the 'AFS' type filesystem (mounted
on /afs) as '0'. Is it likely that your routines are seeing the
'0' inode number and giving up / returning the errors to the
callers?

Thanks for any comments, I will have time later in the month to 
delve into this further, meantime, I'd hope to understand the 
hangup prior to heading down to DC next week for the security 
symp.


-- 
Forrest Whitcher    Principal      FW Systems 
617.254.3506                       fw@fwsystems.com                 
fw@world.std.com                   6174803245@mobile.att.net
Information systems consulting     http://www.fwsystems.com

--
You have received this message because you are subscribed to the selinux 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:[~2001-08-08 17:56 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.SOL.3.95.1010723090133.3466D-100000@clipper.gw.tislabs.com>
2001-08-08 17:56 ` Forrest Whitcher [this message]
2001-08-08 18:19   ` selinux and AFS Stephen Smalley

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=3B717D48.C76441D5@fwsystems.com \
    --to=fw@fwsystems.com \
    --cc=sds@tislabs.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.