On 03/23/2016 08:41 PM, Dominick Grift wrote:
> On 03/23/2016 08:09 PM, Dominick Grift wrote:
>> On 03/23/2016 08:08 PM, Stephen Smalley wrote:
>>> On 03/23/2016 02:37 PM, Dominick Grift wrote:
>>>> On 03/23/2016 07:32 PM, Dominick Grift wrote:
>>>>> On 03/23/2016 06:58 PM, Dominick Grift wrote: <snip>
>>>>>> This seems to be the code:
>>>>
>>>>>>> /* we have to check that this user is allowed to go into
>>>>>>> the range they have specified ... role is tied to an
>>>>>>> seuser, so that'll be checked at setexeccon time */ if
>>>>>>> (mls_enabled && !mls_range_allowed(pamh, defaultcon,
>>>>>>> newcon, debug)) { pam_syslog(pamh, LOG_NOTICE, "Security
>>>>>>> context %s is not allowed for %s", defaultcon, newcon);
>>>>
>>>>>>> goto fail_set;
>>>>
>>>>
>>>>
>>>>> This seems related:
>>>>
>>>>>> class = string_to_security_class("context"); if (!class) {
>>>>>> pam_syslog(pamh, LOG_ERR, "Failed to translate security
>>>>>> class context. %m"); return 0; }
>>>>
>>>>> since:
>>>>
>>>>> pam_selinux(sshd:session): Failed to translate security class
>>>>> context. Invalid argument
>>>>
>>>>> What is a "security class context"?
>>>>
>>>>> Is it choking on the periods in my identifiers?
>>>>
>>>>
>>>> oh sh.. now i get it. It is choking on the "context" security
>>>> class.
>>>>
>>>> Yes i dont have that "user space" access vector because that
>>>> seems to be no longer used.
>>>>
>>>> isnt the context security class a "setransd" thing? if so then
>>>> i do not believe that setransd still uses that. So this should
>>>> probably be adjusted then to not rely on that user space
>>>> access vector?
>
>>> I still see it in use in mcstrans
>>> policycoreutils/mcstrans/src/mcscolor.c: security_class_t
>>> context_class = string_to_security_class("context");
>
>>> Whether or not it ought to be used by pam_selinux is a different
>>> question...
>
>
>> Until recently i used mcstransd on one of my systems, and it never
>> perfomed any checks , that is why i removed that access vector from
>> my policy.
>
>
>
> added the access vector back in but that seems to not make any differenc
> e.
So you are still getting the same error message, right?
>
> _______________________________________________
> Selinux mailing list
> Selinux@xxxxxxxxxxxxx
> To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
> To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
>
--
Miroslav Grepl
Senior Software Engineer, SELinux Solutions
Red Hat, Inc.
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
