Bug 2754 - thinlinc is too sensitive to user name resolution problems
Summary: thinlinc is too sensitive to user name resolution problems
Status: NEW
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VSM Server (show other bugs)
Version: trunk
Hardware: PC Linux
: P2 Normal
Target Milestone: LowPrio
Assignee: Peter Åstrand
Depends on:
Reported: 2008-04-07 13:08 CEST by Erik Forsberg
Modified: 2024-04-16 13:56 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:


Description Erik Forsberg cendio 2008-04-07 13:08:51 CEST
Currently, we're identifying sessions internally in VSM Server/Agent with the username-as-a-string. Using numeric uid instead would make us less vulnerable to trouble in the name service switch subsystem. For example, if an agent has lost its connection to LDAP , verifying session for "kalle" will fail, but verifying session for 2004, kalle's uidNumber, will still work.

Some parts of VSM Agent still needs to know the username, but only during session startup.
Comment 1 Erik Forsberg cendio 2008-04-16 13:21:47 CEST
This is not a trivial change. Lot's of places currently use the username, and we'll probably still want most log messages to keep doing it, which means we'll have to keep both the uid and the username around. 

There are also some API changes between VSM Server and Agent, but that's not a big trouble. 
Comment 2 Pierre Ossman cendio 2008-05-19 08:47:18 CEST
This is a problem I'm seeing fairly often at home. Whenever the LDAP server is a bit lazy, or temporarily down, I get stray Xvnc processes that make my life difficult. This would probably get a lot worse in a cluster as we know that KDE and GNOME do not like multiple instances on different machines, not to mention how gracefully Mozilla handles multiple processes.
Comment 3 Pierre Ossman cendio 2008-07-03 12:45:45 CEST
See also bug 2839.
Comment 5 Pierre Ossman cendio 2017-01-03 11:09:45 CET
Shadowing of users on case-insensitive systems is also broken because we do string comparisons. Comparing UIDs is the proper way to handle those cases.

Note You need to log in before you can comment on or make changes to this bug.