All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ivan Gyurdiev <ivg2@cornell.edu>
To: Joshua Brindle <jbrindle@tresys.com>
Cc: SELinux List <SELinux@tycho.nsa.gov>,
	selinuxdev <selinux-dev@tresys.com>,
	Stephen Smalley <sds@tycho.nsa.gov>
Subject: Re: [PATCH] libsemanage/semanage - permission check for semanage
Date: Thu, 19 Jan 2006 19:11:12 -0700	[thread overview]
Message-ID: <43D046C0.1050400@cornell.edu> (raw)
In-Reply-To: <43D03F2F.6060204@tresys.com>


>> How does the lack of access mean that the store isn't managed?
>
> for all intents and purposes yes, since you can't query or write to it.
I still think that you shouldn't draw conclusions about what the user 
will be doing with the store in a function that answers the question "Is 
the store managed?" Maybe I'll switch to a more privileged user when I 
decide to query or write to the store.
>> I see in seobject, both is_managed, and can_write are called now, 
>> meaning two access checks
>> (and shouldn't they be in the opposite order).
>>
>
> I'd like to bail as soon as possible if you aren't going to be able to 
> write. Since they both do essentially the same checks but can_write is 
> silent it should be first so that the user doesn't see the debug errors.
This doesn't make sense to me, is_managed() should also be silent in the 
success path (meaning, if it can successfully check if the store is 
managed or not).

--
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:[~2006-01-20  2:11 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-19 21:45 [PATCH] libsemanage/semanage - permission check for semanage Joshua Brindle
2006-01-19 22:45 ` Ivan Gyurdiev
2006-01-20  1:38   ` Joshua Brindle
2006-01-20  2:11     ` Ivan Gyurdiev [this message]
2006-01-20  2:19       ` Joshua Brindle
2006-01-20 13:54 ` Stephen Smalley
2006-01-20 14:00   ` Joshua Brindle
2006-01-20 14:24     ` Stephen Smalley
2006-01-20 14:09 ` Stephen Smalley
2006-01-20 14:04   ` Joshua Brindle
2006-01-20 15:20 ` Stephen Smalley
2006-01-20 19:14   ` Joshua Brindle
2006-01-20 20:49     ` Stephen Smalley
2006-01-20 21:25       ` Joshua Brindle
2006-01-23 14:36         ` Stephen Smalley
2006-01-23 14:51           ` Joshua Brindle
2006-01-23 15:29             ` Stephen Smalley
2006-01-23 15:40               ` Joshua Brindle
2006-01-23 15:59                 ` Stephen Smalley
2006-01-23 16:05                   ` Joshua Brindle
2006-01-23 16:18                     ` Stephen Smalley
2006-01-26 20:40                       ` Joshua Brindle
2006-01-27 15:12                         ` Stephen Smalley
2006-01-27 15:17                           ` Joshua Brindle
2006-01-23 16:33                   ` Joshua Brindle

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=43D046C0.1050400@cornell.edu \
    --to=ivg2@cornell.edu \
    --cc=SELinux@tycho.nsa.gov \
    --cc=jbrindle@tresys.com \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux-dev@tresys.com \
    /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.