#4330 otptoken-find doesn't work with non-admin user
Closed: Fixed None Opened 8 years ago by amisnyov.

otptoken-find doesn't find an entry when executing with non-admin user credentials, only without search criteria.

Steps to reproduce:

# kinit admin
Password for admin@IPA.TEST: 
# ipa otptoken-find aa
--------------------
2 OTP tokens matched
--------------------
  Unique ID: aaa
  Vendor: FreeIPA
  Model: totp

  Unique ID: aaaa
  Owner: jdoe
  Vendor: FreeIPA
  Model: totp
----------------------------
Number of entries returned 2
----------------------------
# kinit jdoe
Password for jdoe@IPA.TEST: 
# ipa otptoken-find
-------------------
1 OTP token matched
-------------------
  Unique ID: aaaa
  Owner: jdoe
  Vendor: FreeIPA
  Model: totp
----------------------------
Number of entries returned 1
----------------------------
# ipa otptoken-find aa
--------------------
0 OTP tokens matched
--------------------
----------------------------
Number of entries returned 0
----------------------------

This is expected. Non-admin users are not expected to see each other's tokens. We have following ACI in place:

aci:(targetfilter = "(objectClass=ipaToken)")(targetattrs = "objectclass || ipatokenUniqueID ||    description || ipatokenOwner || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial")(version 3.0; acl "Users can read basic token info"; allow (read, search, compare)    userattr = "ipatokenOwner#USERDN";)

which only allows token owner (or admin) to see it. It is governed by ipatokenOwner attribute of the token.

Opening again, I misunderstood Adam's point - sorry. I thought he is complaining that admin's token is not visible to jdoe, but he was rather pointing to the fact that term search did not work even though it should.

Nathaniel's assessment welcome.

I don't think this is an OTP issue. The ACI permits read, search and compare. And the ACI is obviously being evaluated, otherwise the "Unique ID" field would not be shown in the non-search otptoken-find. And search against ipatokenuniqueid obviously works because it works for the admin.

So in short, I think this is a framework bug.

This is already fixed in upstream:

$ kinit admin
ipa otptoken-find
--------------------
2 OTP tokens matched
--------------------
  Unique ID: aa
  Description: foo
  Owner: admin
  Manager: admin
  Vendor: FreeIPA
  Model: totp

  Unique ID: aaa
  Description: foo
  Owner: fbar
  Vendor: FreeIPA
  Model: totp
----------------------------
Number of entries returned 2
----------------------------

$ kinit fbar

$ ipa otptoken-find aa
-------------------
1 OTP token matched
-------------------
  Unique ID: aaa
  Description: foo
  Owner: fbar
  Vendor: FreeIPA
  Model: totp
----------------------------
Number of entries returned 1
----------------------------

$ ipa otptoken-find
-------------------
1 OTP token matched
-------------------
  Unique ID: aaa
  Description: foo
  Owner: fbar
  Vendor: FreeIPA
  Model: totp
----------------------------
Number of entries returned 1
----------------------------

Metadata Update from @amisnyov:
- Issue assigned to someone
- Issue set to the milestone: FreeIPA 4.0 - 2014/06

5 years ago

Login to comment on this ticket.

Metadata