[Freeipa-devel] Draft: Read permissions for user

Martin Kosek mkosek at redhat.com
Wed Apr 16 13:08:28 UTC 2014


On 04/15/2014 04:55 PM, Petr Viktorin wrote:
> Hello,
> At Devconf, we decided what most of the default read permissions should look
> like, but we did not get to user.
> Here is a draft of 4 read permissions. Please comment.
> 
> 
> Basic info (anonymous):
> [top]
>     objectclass
> [person]
>     cn, sn, description
> [organizationalPerson]
>     title
> [inetOrgPerson]
>     uid
>     displayName, givenName, initials
>     manager
> [inetUser]
>     memberOf

<== We originally specifically hidden memberOf attribute from anonymous users.
I think we should continue hiding it.

> [ipaObject]
>     ipaUniqueID
> [ipaSshUser]
>     ipaSshPubKey
> [ipaUserAuthTypeClass]
>     ipaUserAuthType
> [posixAccount]
>     gecos, gidNumber, homeDirectory, loginShell, uidNumber
> 
> 
> Details (all authenticated):
> [person]
>     seeAlso, telephoneNumber
> [organizationalPerson]
>     fax, l, ou, st, postalCode, street
>     destinationIndicator, internationalISDNNumber, physicalDeliveryOfficeName,
>         postalAddress, postOfficeBox, preferredDeliveryMethod,
>         registeredAddress, teletexTerminalIdentifier, telexNumber, x121Address
> [inetOrgPerson]
>     carLicense, departmentNumber, employeeNumber, employeeType,
>         preferredLanguage, mail, mobile, pager
>     audio, businessCategory, homePhone, homePostalAddress, jpegPhoto,
>         labeledURI, o, photo, roomNumber, secretary, userCertificate,
>         userPKCS12, userSMIMECertificate, x500UniqueIdentifier
> [inetUser]
>     inetUserHttpURL, inetUserStatus
> [ipaUser]
>     userClass

I would personally not divide the attributes as basic and detailed. IMO it is
our artificial distinction and may vary between deployments. Why would we for
example show inetUserHttpURL to authenticated only and ipaSshPublicKey to everyone?

My proposal would be to have a permission "Read User Information" for all
attributes above.


> Kerberos/login-related (all authenticated):
> [krbPrincipalAux]
>     krbPrincipalName, krbCanonicalName, krbPrincipalAliases,
>     krbPrincipalExpiration, krbPasswordExpiration, krbLastPwdChange
> [+]
>     nsAccountLock

Ok. So permission "Read User Kerberos Attributes"?

> 
> 
> Kerberos-related (user admins only):
> [krbPrincipalAux]
>     krbLastSuccessfulAuth, krbLastFailedAuth, krbLastPwdChange

So permission "Read User Kerberos Login Attributes"?

I think this group should also have:

krbLastAdminUnlock
krbLoginFailedCount

> No read permission:
> [person]
>     userPassword

ok

> [krbPrincipalAux]
>     krbPrincipalKey, krbExtraData, krbPwdHistory

ok

>     krbLastAdminUnlock,

Move this one.

>     krbLoginFailedCount

Move this one.

> krbPrincipalType

Simo? I know we do not user this attribute, but wouldn't it fit in "Read User
Kerberos Attributes" permission?

> krbPwdPolicyReference

This could contain DN to user's password policy attribute. IMO somebody should
have a right to read it. Simo, should all authenticated users be able to read it?

>         krbTicketPolicyReference, krbUPEnabled

I would treat those the same as krbPwdPolicyReference.

> [krbTicketPolicyAux]
>     krbMaxRenewableAge, krbMaxTicketLife, krbTicketFlags

Ok. This will be readable by people with "System: Read User Kerberos Ticket
Policy" permission.

> [mepOriginEntry]
>     mepManagedEntry

This is used to bind user to it's private group. We use it for example in
group-detach command to distinguish between managed and non-managed groups.

We may want to show it to all authenticated users.

Martin




More information about the Freeipa-devel mailing list