[Progress record]:
Proposed time: 2022/03/01
Discussion time: 2022/04/01
Accept/Reject Time: 2022/04/30
Completion time: 2022/05/21
[issues]: https://github.com/apache/incubator-linkis/issues/xxxxx  
[email]: At present, discussions must be initiated in the WeChat group [Apache Linkis Community Development Group], and the discussion minutes can be sent to the official dev mailbox of linkis  
【Release】：Linkis-1.1.1

Compatibility, Deprecation and Migration Plans
61. What is the impact on users of the existing version?
    none
62. If we are changing certain treatments, how are we going to phase out old treatments?
    none
63. If we need special upgrade tools, please describe them here?
    none
64. When will we remove existing treatments?
    none

Follow-up - Supplement of design data (the first draft needs to be given before the development, and the development process is gradually revised and supplemented. Before the development is completed, the detailed information needs to be supplemented)
1. Changes in the code module module
If yes, please list
2. Changes in http interface
If yes, please list
3. Changes in the client interface
If yes, please list
4. Adjustment of database table structure
If yes, please list
5. Adjustment of configuration file parameters
If yes, please list
6. Changes in error codes
If yes, please list
7. Third-party dependencies that need to be introduced
If yes, please list

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation & Background

At present, when linkis is executing the task submitted by the user, the main process service of linkis will switch to the corresponding user through sudo -u ${submit user}, and then execute the corresponding engine startup command, which requires each ${submit user} in advance Create the corresponding system user and configure the relevant environment variables. For new users, a series of environment initialization preparations are required. Frequent user changes will increase operation and maintenance costs, and there are too many users, so resources cannot be configured for a single user, and resources cannot be well managed. If the A agent can be executed to the designated agent user, the execution entry can be converged uniformly, and the problem of needing to initialize the environment can be solved. 

Basic concept

Login user: The user who directly logs in to the system through the user name and password

Proxy user: The user who actually performs the operation as the login user is called the proxy user, and the related operations of the proxy login user

Expect to achieve goals

● Log in user A can choose a proxy user and decide which proxy user to proxy to

● Login user A can delegate tasks to proxy user B for execution

● When logging in to user A as proxy to proxy user B, you can view B-related execution records, task results and other data

● A proxy user can proxy multiple login users at the same time, but a login user can only be associated with a certain proxy user at the same time

Implementation plan

● Modify the cookie processing of the existing interface, which needs to be able to parse out the logged-in user and proxy user in the cookie 

The key of the proxy user's cookie is: linkis_user_session_proxy_ticket_id_v1
Cookie for logged in user: linkis_user_session_ticket_id_v1

● The related interface of linkis needs to be able to identify the proxy user information on the basis of the original UserName obtained, and use the proxy user to perform various operations. And record the audit log, including the user's task execution operation, download operation

● When the task is submitted for execution, the entry service needs to modify the user to be the proxy user.

Things to Consider & Note:

● Users are divided into proxy users and non-proxy users. Can proxy users still perform proxy execution to other users?

● It is necessary to control the list of logged-in users and system users who can be proxied, to prohibit the occurrence of arbitrary proxies, and to avoid uncontrollable permissions. It is best to support database tables to configure, and can be directly modified to take effect without restarting the service

● Separately record log files containing proxy user operations, such as proxy execution, function update, etc. All proxy user operations of PublicService are recorded in the log, which is convenient for auditing 

Changes

Compatibility, Deprecation, and Migration Plan

• What impact (if any) will there be on existing users?
• If we are changing behavior, how will we phase out the older behavior?
• If we require special migration tools, describe them here.
• When will we remove the existing behavior?