Re: Why "id -Z" get the current process security context but says "of the current user" in help?

[Yang Chengwei]

On Thu, Jan 16, 2014 at 02:16:28AM +0000, Pádraig Brady wrote:
> On 01/16/2014 01:50 AM, Yang Chengwei wrote:
> > Hi List,
> > 
> > I found that both id manpage and its help info says something about
> > security context like:
> > 
> >   -Z, --context  print only the security context of the current user\n\
> > 
> > As it said, it gets the security context of *the current user*. However,
> > I found in its source code, it implemented in a way to get *the current
> > process* security context, in both SELinux and SMACK way.
> > 
> > As I understand, *the current process* whenever "id -Z" executed, it's
> > the id process, its security context doesn't equal *the current user*
> > security context. Right?
> > 
> > So far I haven't worked with SELinux a lot, but have some SMACk
> > experience, so currently "id -Z" in SMACK environment *only* works if *id*
> > hasn't itself SMACK64EXEC label, in that way, *id* will inherent the shell
> > security context, so the security context of *the current process* is
> > the same as security context of *the current user*. Otherwise, it will
> > surprise user, like me.
> 
> There was a large change to SELinux handling recently,
> but this functionality or --help output didn't change.
> 
> You're right that this just prints the context for
> the id _process_, and also one can specify a particular user:
> 
>   $ id -u $USER -Z
>   id: cannot print security context when user specified
> 
> So I suppose we might change the --help docs etc. to say
> _process_ rather than _user_.  Is SMACK64EXEC a common

That's fine to me, and I'd like to submit such a simple patch to do so.

> label to have set on the id executable? Jarkko I don't suppose

Yes, SMACK64EXEC is a label when the file is running, so as a *subject*
in SMACK. A file if has SMACK64EXEC setup, then it will running with
that label, which overwrite the one inherent from its parent, say the
current shell for example.

> there is any way to avoid that?

I think so.

--
Thanks,
Chengwei

> 
> thanks,
> Pádraig.

signature.asc
Description: Digital signature