[SERVER-34820] buildInfo fails when no users are authenticated Created: 03/May/18  Updated: 19/Dec/18  Resolved: 22/Oct/18

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 3.6.0, 3.6.1, 3.6.2, 3.6.3, 3.6.4, 3.7.9
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Bernie Hackett Assignee: Misha Tyulenev
Resolution: Duplicate Votes: 0
Labels: sharding-wfbf-day
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
is depended on by PYTHON-1547 server_info() doesn't work without au... Closed
Duplicate
duplicates SERVER-38390 Set requiresAuth to false for certain... Closed
Related
Operating System: ALL
Steps To Reproduce:

Steps:

  • Start a single mongod
  • Add one user to the admin database
  • Without authenticating first attempt to call buildinfo using a driver that uses implicit sessions (e.g. PyMongo 3.6+).

 

 

Sprint: Sharding 2018-09-24, Sharding 2018-11-05
Participants:

 Description   

This seems similar to SERVER-32063:

>>> c.admin.add_user('foo', 'bar')
>>> c.server_info()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/sigstop/work/mongo-python-driver/pymongo/mongo_client.py", line 1464, in server_info
    session=session)
  File "/home/sigstop/work/mongo-python-driver/pymongo/database.py", line 532, in command
    codec_options, session=session, **kwargs)
  File "/home/sigstop/work/mongo-python-driver/pymongo/database.py", line 439, in _command
    client=self.__client)
  File "/home/sigstop/work/mongo-python-driver/pymongo/pool.py", line 515, in command
    collation=collation)
  File "/home/sigstop/work/mongo-python-driver/pymongo/network.py", line 126, in command
    parse_write_concern_error=parse_write_concern_error)
  File "/home/sigstop/work/mongo-python-driver/pymongo/helpers.py", line 145, in _check_command_response
    raise OperationFailure(msg % errmsg, code, response)
pymongo.errors.OperationFailure: there are no users authenticated
>>> c.server_info()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/sigstop/work/mongo-python-driver/pymongo/mongo_client.py", line 1464, in server_info
    session=session)
  File "/home/sigstop/work/mongo-python-driver/pymongo/database.py", line 532, in command
    codec_options, session=session, **kwargs)
  File "/home/sigstop/work/mongo-python-driver/pymongo/database.py", line 439, in _command
    client=self.__client)
  File "/home/sigstop/work/mongo-python-driver/pymongo/pool.py", line 515, in command
    collation=collation)
  File "/home/sigstop/work/mongo-python-driver/pymongo/network.py", line 126, in command
    parse_write_concern_error=parse_write_concern_error)
  File "/home/sigstop/work/mongo-python-driver/pymongo/helpers.py", line 145, in _check_command_response
    raise OperationFailure(msg % errmsg, code, response)
pymongo.errors.OperationFailure: there are no users authenticated

2018-05-03T08:57:22.266-0700 D COMMAND  [conn2] run command admin.$cmd { buildinfo: 1, lsid: { id: UUID("103f4218-e907-476d-b5b4-43be95a8fb89") }, $readPreference: { mode: "secondaryPreferred" }, $db: "admin" }
2018-05-03T08:57:22.266-0700 D -        [conn2] User Assertion: 13:there are no users authenticated src/mongo/db/auth/authorization_session.cpp 206
2018-05-03T08:57:22.266-0700 D COMMAND  [conn2] assertion while executing command 'buildinfo' on database 'admin' with arguments '{ buildinfo: 1, lsid: { id: UUID("103f4218-e907-476d-b5b4-43be95a8fb89") }, $readPreference: { mode: "secondaryPreferred" }, $db: "admin" }': Unauthorized: there are no users authenticated
2018-05-03T08:57:22.266-0700 I COMMAND  [conn2] command admin.$cmd command: buildInfo { buildinfo: 1, lsid: { id: UUID("103f4218-e907-476d-b5b4-43be95a8fb89") }, $readPreference: { mode: "secondaryPreferred" }, $db: "admin" } exception: there are no users authenticated code:Unauthorized numYields:0 reslen:119 locks:{} protocol:op_query 0ms

This only happens when the driver uses implicit sessions (e.g. PyMongo 3.6+). Using an older driver without implicit sessions (e.g. PyMongo 3.5.x) works around the problem.

 



 Comments   
Comment by Ryan Salt [ 19/Dec/18 ]

greg.mckeonmisha.tyulenev, thank you for fixing 

Comment by Gregory McKeon (Inactive) [ 19/Dec/18 ]

This issue has been resolved in 3.6.10 by SERVER-38390.

Comment by Misha Tyulenev [ 21/Nov/18 ]

ryansalt-eri 3.6 Required will prioritize scheduling the backport in one of the upcoming releases of 3.6. I don't have information about exact release it will be in.

Comment by Ryan Salt [ 21/Nov/18 ]

misha.tyulenev, thanks for the quick response! The required backport you mention, is that a backport of improvements made under SERVER-34653, and if so do you have any idea when this may land in v3.6? (I couldn't see it listed in Release 3.6.10 or 3.6 Required)

Comment by Misha Tyulenev [ 21/Nov/18 ]

ryansalt-eri this is the correct approach. To address the issue the requiresAuth method should return false for several commands including buildInfo. We will make this change as a part of the required backport.

Comment by Ryan Salt [ 21/Nov/18 ]

misha.tyulenev, considering this issue was marked as a duplicate of SERVER-34653, which was not backported to v3.6, would you support a partial port to address this bug for v3.6.10? It would simply require adding the override of requiresAuth method returning false to the buildInfo command class.

Comment by Misha Tyulenev [ 22/Oct/18 ]

greg.mckeon i think so - its not backported to 3.6, only 4.0, shane.harvey please confirm

Comment by Misha Tyulenev [ 27/Sep/18 ]

jack.mulrow thats right the SERVER-35753 has the list of commands that should not require auth and it includes connectionStatus

Comment by Jack Mulrow [ 27/Sep/18 ]

misha.tyulenev I'm running into this same issue with connectionStatus while backporting SERVER-32064. The problem seems to be some commands that don't require auth privileges don't also explicitly specify requiresAuth=false in their definitions, so their session info isn't stripped away (as per SERVER-30298). I think the fix is to just go through the commands that don't require auth starting from 3.6 and make sure they also explicitly declare requiresAuth=false if we want them to work with implicit sessions. SERVER-35463, SERVER-35382, and SERVER-34653 already did this for a few commands in 4.0.

CC max.hirschhorn

Comment by Shane Harvey [ 21/Sep/18 ]

misha.tyulenev, it looks like connectionStatus and listCommands suffer from the same bug as buildInfo. SERVER-35753 has the list of commands that should not require auth.

Comment by Jeffrey Yemin [ 12/Jun/18 ]

sessions are intended to be used by authenticated users

I don't think that intention was well understood since we agreed to enable implicit sessions in drivers even for unauthenticated connections.

Do we undo the implicit session work from 3.6 for helpers like this, or do we tell our users too bad, you need to authenticate now

It's not only explicit helpers. Generic run command is also problematic, e.g. db.runCommand({buildInfo : 1}) will fail as well for unauthenticated connections.

Comment by Bernie Hackett [ 12/Jun/18 ]

Is there a list of commands that only require auth when an implicit session is used? I'd like to know what else is going to break. This puts drivers in a bad situation. Do we undo the implicit session work from 3.6 for helpers like this, or do we tell our users too bad, you need to authenticate now?

Comment by Kaloian Manassiev [ 11/May/18 ]

buildInfo is a command which is allowed to be called unauthenticated and sessions are intended to be used by authenticated users, so this is expected behaviour.

Comment by Kaloian Manassiev [ 11/May/18 ]

misha.tyulenev, is this one of the commands for which we need to disallow sessions?

Comment by Gregory McKeon (Inactive) [ 07/May/18 ]

You can't add an lsid to buildInfo without having a logged in user in the current implementation. Assigning to sharding since they own sessions.

Comment by Bernie Hackett [ 03/May/18 ]

This problem also exists in 3.7.x.

Comment by Bernie Hackett [ 03/May/18 ]

Note that SERVER-12143 may put buildinfo behind auth, but that hasn't happened yet.

Generated at Thu Feb 08 04:37:57 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.