All of lore.kernel.org
 help / color / mirror / Atom feed
From: cpebenito@tresys.com (Christopher J. PeBenito)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] Side effects for the comments in the .if files?
Date: Tue, 30 Nov 2010 10:13:04 -0500	[thread overview]
Message-ID: <4CF51480.7000903@tresys.com> (raw)
In-Reply-To: <SNT139-w619C399106512634B01DD2AB3D0@phx.gbl>

On 11/22/10 06:11, HarryCiao wrote:
> Hi SELinux expert,
> 
> I seems to run into something that I could not understand - the comment
> in the .if file would have an impact on how the .pp files is compiled.
> Sometime the comments in the .if file may block the interfaces called to
> be properly parsed, and if all comments are removed, then the called
> interfaces could be parsed correctly to grant the desired permissions
> for the calling domain.
> 
> For example, in my v5-samhain.pp implementation(please refer to another
> separate email), the samhain_service_template() calls
> userdom_use_user_terminals($1_t) in the end, but I am very surprised to
> find that the samhain_t lacks privileges to access user_devpts_t when
> deployed on the target. However, if all comments are removed in
> samhain_service_template(), then the call to
> userdom_use_user_terminals($1_t) could actually take effect, and I could
> verify following lines added to tmp/samhain.tmp:
> 
> +             ;   type user_tty_device_t, user_devpts_t;
> +#line 38
> +       
> +#line 38
> +               } # end require
> +#line 38
> +       
> +#line 38
> +
> +#line 38
> +
> +#line 38
> +       allow samhain_t user_tty_device_t:chr_file { getattr open read
> write append ioctl };
> +#line 38
> +       allow samhain_t user_devpts_t:chr_file { getattr open read write
> append ioctl };
> +#line 38
> 
> Moreover, comments in the .te files do not seem to have such side
> effect, they only do in the .if files. What's going on here? Is there
> dark magic and anything particular I should watch out when using
> comments in the .if files?

The only issue I can think of is if you accidentally use a m4 quote in a
comment.  For example a line like this:

# don't do this

If this is in an interface, the apostraphe (') will be interpreted as
the end of the block, which typically means the interface will end
prematurely.  However, userdom_use_user_terminals() does not have any
comment issues, so I'm unsure why you're seeing an issue.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

  reply	other threads:[~2010-11-30 15:13 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-22 11:11 [refpolicy] Side effects for the comments in the .if files? HarryCiao
2010-11-30 15:13 ` Christopher J. PeBenito [this message]
2010-12-04 12:57   ` HarryCiao

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=4CF51480.7000903@tresys.com \
    --to=cpebenito@tresys.com \
    --cc=refpolicy@oss.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.