Page MenuHomePhabricator

Non-existent users in the archiva-deployers LDAP group
Closed, ResolvedPublicSecurity


See for example

Apparently this is Milimetric in the list, which displays right on other ldap lists he's on as in

Wondering if he was added with a bad format via LDAP (tempted to tag with SRE but I prefer someone to see if there's anything wrong in the coding of the tool first).

He's not the only example. Multiple instances of <unknown users> can be found on the other listings.

Event Timeline

MarcoAurelio changed the subtype of this task from "Task" to "Bug Report".May 22 2019, 11:40 AM

18:03 < hauskatze> mutante: is caused by an LDAP issue or it's the tool not fetching the data correctly?
18:03 < hauskatze> milimetric appears in archiva-deployers as '<unknown user>'
18:06 < mutante> hauskatze: when i use "[mwmaint1002:~] $ sudo modify-ldap-group archiva-deployers
18:06 < mutante> then i see both as normal members
18:06 < mutante> and i have never seen "unknown user" before when using the tools on the server
18:07 < mutante> so i would tend to "not fetching correctly" / somewhere later in the chain of things
18:08 < mutante> hauskatze: did any of them mention not being able to login or is this just a display issue
18:09 < mutante> hauskatze: interesting is also if you hover your mouse over the "more info" link you still get the user name
18:09 < mutante> so it somehow knows it
18:09 < mutante> just doesn't display it right
18:09 < hauskatze> just a display issue I noticed after updating the tool to display all avalaible ldap groups
18:09 < mutante> seems more like a bug in the then
18:09 < hauskatze> (which I'm not sure it's listing them all, because I have to manually populate the list each time a new ldap group is created)
18:11 < mutante> hauskatze: ooh.. just noticed a new issue
18:11 < mutante> [mwmaint1002:~] $ ldaplist -l passwd iflorez
18:11 < mutante> The search returned an error.
18:11 < mutante> this is not how it used to be
18:11 < quiddity> Sidenote: It is Not related to the case-sensitive problem that was fixed a few months ago. Because those users are not in the list at (which was my first guess)

18:12 < mutante> but also ldaplist was supposed to be removed on 30 august 2016
18:12 < quiddity> >.<
18:13 < mutante> hauskatze: more interesting stuff.. if you look at the "more info" links. for users that appear normal it looks like this:
18:13 < mutante>
18:13 < mutante> for a user that shows as "unknown" it looks like this:
18:13 < mutante>
18:13 < hauskatze> mutante: yup, that's how I discovered the usernames for the 'unknown' ones :)
18:13 < mutante> some parsing issue
18:15 < hauskatze> okay then, if everything is okay on the ldap-side
18:15 < mutante> i dont know why ldaplist returns an error
18:15 < mutante> so kind of
18:15 < mutante> but if that was generally broken i would expect all users to be unknown and not 2 random ones
18:16 < mutante> nobody in the "wmf" group currently shows as unknown
18:18 < mutante> hauskatze: line 67 in is where it happens.. but dont know why

Legoktm set Security to Software security bug.Jul 9 2019, 10:48 PM
Legoktm added a project: acl*security.
Legoktm changed the visibility from "Public (No Login Required)" to "Custom Policy".
Legoktm triaged this task as Unbreak Now! priority.Jul 9 2019, 10:51 PM

The users millimetric and ottomata in the archiva-deployers LDAP group do not exist. Theoretically anyone could create those account names and gain access to the group.

They should be milimetric (just one l) and otto per and

Restricted as a security task for now.

Legoktm renamed this task from ldap tool returns <unknown user> sometimes to Non-existent users in the archiva-deployers LDAP group.Jul 9 2019, 10:51 PM
Legoktm added a project: LDAP.

I tried to fix the user names in the archiva-deployers group but i could not save my edits. I got:

ldap_modify: Server is unwilling to perform (53)
	additional info: operation restricted

So i tried to find another root or member of ldap-admin to confirm if that is just me or broken for everybody.

turns out this was caused by from

and fixed by

The LDAP servers were set to readonly.

After that i was able to make the fixes. I changed "ottomata" to "otto" and "millimetric" to "milimetric" and now there are no more unknown users.

Dzahn claimed this task.

There's a remaining "unknown" user at The more info link returns an invalid username error message.

MarcoAurelio changed the subtype of this task from "Bug Report" to "Security Issue".Jul 10 2019, 9:40 AM

That is not a fix. Which tool(s) broke in specific? They need to be fixed to use and not reuse a random WMCS config.

currently there seems to be no difference between "ldap-eqiad" and "ldap-labs-eqiad" though is an alias for is an alias for

Which tool(s) broke in specific?

modify-ldap-group and also it changed the config in /etc/ldapvi.conf, so ldapvi as well.

ldaplist -l <user> also stopped working but that seems to be a separate issue from the ro issue since it did not go away after the merge above.

Legoktm changed the visibility from "Custom Policy" to "Public (No Login Required)".Dec 29 2023, 7:46 PM