Oliver Burtchen wrote:
> Am Montag, 3. Mai 2010 23:16:46 schrieb Sumit Bose:
>> On Mon, May 03, 2010 at 10:51:10PM +0200, Oliver Burtchen wrote:
>>> Am Montag, 3. Mai 2010 21:17:35 schrieb Dmitri Pal:
>>>> Stephen Gallagher wrote:
>>>>> On 05/03/2010 02:55 PM, Rob Crittenden wrote:
>>>>>> Oliver Burtchen wrote:
>>>>>>> What are the exact service-names to use in --service? I know
>>>>>>> basically they are the ones like in /etc/services, or what pam
>>>>>>> uses. But I noticed that both ssh and sshd are applicable for ssh.
>>>>>>> Is there somewhere a list or do they provide it by their selfs, and
>>>>>>> I can only make a good guess and try.
>>>>>> To be honest, I'm not sure myself. I'm guessing that sssd has a
>>>>>> mechanism for determining this. I've filed
>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=588412 to track this
>>>>>> question.
>>>>> I'm going to let Sumit comment on the Bugzilla ticket, since he'd
>>>>> know better, but I'm 99% certain that we get this directly from PAM
>>>>> (as in, the application itself provides that data when making a PAM
>>>>> request).
>>>>> Looking at a recent auth I performed on my system, I see the raw PAM
>>>>> data that comes in from (for example) 'su -l' is reported to us as
>>>>> "service: su-l".
>>>>> My assumption is that SSSD's HBAC simply treats that as canonical.
>>>> Thanks for reminding me. It now rings the bell. The service name is
>>>> what application provides when uses pam calls. There is no full
>>>> enumeration. It is whatever is used by an application.
>>>> Having a good list would be nice though, at least identifying the
>>>> applications that we already know use specific service names.
>>> For the record: After reading Sumits reply at bugzilla and this
>>> "In general, the service name is the name of the program used to access
>>> the service, not the program used to provide the service. This is why the
>>> service wu-ftpd, defines its service name as /etc/pam.d/ftp." quoted from
>>> http://www.redhat.com/docs/manuals/linux/RHL-8.0-Manual/ref-guide/s1-pam-
>>> config-files.html
>>> I tested it a little bit out:
>>> If you set a hbac-rule with --service=su-l, it will only apply to "su -l"
>>> or "su -", but not to a simple "su".
>>> If you set a hbac-rule with --service=su, it will apply to "su -l", "su
>>> -"and a simple "su".
>>> So my assumption is, that applications do try from a specific name, down
>>> to the general one. This is why "sshd" and "ssh" work. Or is it pam who
>>> does this magic?
>> No it is not PAM, but some kind of error on my side. The strings sssd gets
>> from the LDAP server are not terminated with \0, but the size is known
>> (this is because the ASN.1 coding of the LDAP messages). I was lazy and
>> just compared up to the length return by LDAP. Although the effect might
>> look convenient I think this is an error. I'll try to fix it tomorrow.
> Yes, at first sight it looked convenient. But arghh, currently a hbac-rule 
> for 
> "su" also matches "sudo"? Well, good to nailed it down.  ;-)   I'll 
> appreciate 
> your corrections.
> But despite that it would be very nice to have some way to set a rule for a 
> "category" or group of services. It is very error-prone to administer the 
> same 
> set of rules for example for ssh, su, login seperately. I can think of 
> different approaches to achieve that, but don't know what's best.
> Maybe it should be possible to collect services in a group. Then the frontend 
> (cli or webui) could apply modifications to all members of this named group, 
> if 
> asked so?
> Best regards,
> Oli

That would require schema changes. It is doable but I am not sure is the
best approach.
I would rather suggest we treat the value as a space separated list or a
MV attribute and have a way to create MV values in a simpler ways.
We need to think about it.

I will file an ER.

>> bye,
>> Sumit
>>> Btw: I also think a good list with well known services would be nice, so
>>> someone who tries to set up wu-ftpd, like the example in the redhat-docu,
>>> uses "ftp", and not "wu-ftpd". It's just a wish for the upcomming
>>> documentation. ;-)
>>> Best regards,
>>> Oli
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users

Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.

Looking to carve out IT costs?

Freeipa-users mailing list

Reply via email to