Regular users start GUI with root privileges

Python Help
21

You are right.

I realize that I am in a luxury position taking over a 15 year old FOSS project. It is still in Debian, Arch on all other.

22

Yes, it’s a pretty normal situation. All executables you run daily like rm (aka /usr/bin/rm) or your usual apps installed from the distro are owned by root.

Why? This is what sudo pip install does. I don’t see the difference between sudo pip install and your old Make-based build system.

At this point, I think I’m not following what the state of your question is. Have you solved your problem? If not, what issues remain?

2 Likes
23

Running pip as root is seen as a very bad idea and it is blocked by default it can and has broken linux systems.

Building a venv with the app code in it is what you are supposed to do now.

1 Like
24

Yup, I agree with that. I’m just saying that it is probably an equivalent of what the old build system does, and therefore I don’t understand what the OP could do before that he cannot do anymore (although whether he should continue to do that is another question).

3 Likes
25

Good question. :smile: I think the discussion run into several directions I have to take a break think about all your comments. But I would say this was one intention of this thread to got some insides and opinions of experienced Python packagers.

If my problem is solved? Not sure. This depends on my needs. And the later is one aspect I am not totally sure about.

But would this solve the run as root situation, too? Or do you mean I should create this venv as root?

By the way: Again I have to say thank you to you all. I experience this community as very friendly and helpful.

26

Yes create as root, since you do not want to package.

27

OK. Some days and nights have passed. I have thought about how to instruct other people about how to use my repository.

In my opinion the reason for my confusions is that I do mix “regular users” (install, run and clicking around) and “developers” (modifying the code). With this two roles in mind I would suggest them like this:

  1. Using virtual environments is recommended in all use cases and for all user roles.
  2. Regular users should install the package as root, e.g. via sudo pip ....
  3. Developers using Developer Mode (--editable) should install it as user to have appropriated permissions to edit the py files. But in that case developers should be aware of the security implications.

What do you think?

28

This is a very bad idea. It has lead to linux systems breaking critical system tools.
Pip will refuse to run unless you override the safety checks.

3 Likes
29

Not sure if I understand you correct here.

Of course it is implicit that the user need to do this in a virtual environment (even as sudo/root) or use pipx. Would it be OK in that case?

30

Venv is fine, but that is not what you wrote.

1 Like
31

I do expect my intelligent users doing this them self. And of course I would add a use-a-virtuel-env-everytime-section in the beginning of my howto-like document.

The point is that there are several ways (commands) to create a virtual env. And I won’t restrict users to one of them.

32

If you are using virtual environments, then being root shouldn’t ordinarily do anything useful while creating them or installing to them, if I’m thinking straight.

If your project has dependencies that must be installed as root, normally that would involve the system package manager and a README.

2 Likes
33

OK, the question was what is my problem and what do I want. :stuck_out_tongue_winking_eye:

  1. I want migrate from make build-system to Python build system.
  2. I want to get rid of make! I don’t want to maintain two parallel build systems.
  3. There are two “roles” of people: Users and Developers. Users shouldn’t use Python build system but just there GNU Linux distro repo. If they really want to install from upstream they need to do this own there own risk.
  4. Beside virtual environments and editable installs to go further with development, developers sometimes need to “install as users” just to test and debug some things from a users perspective. But they need to to this with upstream code state and they can not wait until the distro maintainers releasing a new deb/rpm-package version.

In summary: Users are not the problem because they shouldn’t use Python build system. But the developers need an elegant and maintainable way to deal with the application, its development (editing py files) and manual testing (install and run it like a user).

Problems:
Pip or Pipx, with and without virtual environments, as user, as sudo or as root do not help. Installing as root (or sudo) makes it impossible for a regular user to execute the binary.

I tried to use the environment variable PIPX_BIN_DIR to “install” the entry point script in a directory available by users and root.

$ sudo su
# export PIPX_BIN_DIR=/usr/bin
# pipx install .
# ls -l /usr/bin/usergui
lrwxrwxrwx 1 root root 47  3. Mär 13:15 /usr/bin/usergui -> /root/.local/pipx/venvs/rootusergui/bin/usergui

Not really installed, just symlinked. OK, but this might be one step in the right direction?

There is also the PIPX_LOCAL_VENVS to modify the location of virtual environments. But it is read only and need to be modified indirect via setting PIPX_HOME:

# export PIPX_BIN_DIR=/usr/bin
# export PIPX_HOME=/usr/local/pipx
# pipx install .

Great. Seems to work. I can now execute the two entry point scripts as root and as user. And when doing rootgui as user the expected pkexec password prompt popup. Awesome.

To my understand this also solves the security problem. The py files are still owned and editable only by root.

1 Like