Re: secon (Was: Policycoreutils patch)

[James Antill <jantill@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2112 bytes --]

On Mon, 2006-05-08 at 10:54 -0400, Stephen Smalley wrote:
> What is the purpose of the secon utility added by this patch?
> Assuming that it is useful, a few quick comments on the implementation:
> - The my_getXcon_raw functions should be moved into libselinux (without
> the my_ prefix, of course) so that we don't need any code outside of
> libselinux directly reading /proc/pid/attr files.

 Yes, I'd known about that ... I'll be providing changes for libselinux
in the next day or so.
 The initial version with my_ functions was simply to make it easier for
others to be able to compile the code.


> - Falling back to the current context when the exec or fscreate context
> is not set is not correct.  Absence of exec or fscreate context just
> means that the default policy behavior (e.g. type_transition or default
> inheritance) will be applied.  While default inheritance would mean that
> the current context is applied for exec, there could be a
> type_transition, and it makes no sense at all for fscreate (where
> default inheritance combines information from the current context with
> the parent directory context).  I think you just want to report NULL /
> none or similar to the user.

 I was wary of reporting just a blank, but it's a simple change to fix
that.


> - The call to selinux_trans_to_raw_context() doesn't make sense since
> you are already calling the _raw functions.  If opt->disp_raw is set,
> then no further processing should be required, right?

 If the context comes from the user (Ie. stdin or argument), we don't
know if the context is raw or translated. So we always convert. This
allows:

id -Z | secon -R -

...to output the right thing.
 The other thing we are looking at is what the default should be, Steve
Grubb suggested that reading from stdin should be it ... but I don't
like that from a UI POV and that most cases are better handled otherwise
(Ie. ls -Z is never going to be parsable, IMO, so secon -f is much
better).

-- 
James Antill
<james.antill@redhat.com>

-- 
James Antill
<james.antill@redhat.com>


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]