0

I have Python code that is run using a bash script. I want non-sudo users to be able to run it without making the Python code readable. What is the recommended pattern?

Two ways I considered:

  1. Put all code under user's HOME and make it non-readable and executable as necessary
  2. Put all code under /usr/local and add relevant bash scripts to sudoers
  3. Put all code under /root and add relevant bash scripts to user's PATH or bin folder

As there are several ways to structure this, I'd love to hear what you think the standard or recommended way is.

closed as too broad by Thomas Dickey, Stephen Rauch, RalfFriedl, schily, John WH Smith Sep 9 '18 at 11:44

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Why do you need the code to be kept secret? That's generally not a good thing to do. – Joseph Sible Sep 8 '18 at 18:32
  • I'm ok with the bash script being readable but the Python codebase is proprietary and needs to be closed source – tsotsi Sep 8 '18 at 18:36
  • Why though? Did you hardcode passwords in it or something, or are you just worrying about the algorithm itself? – Joseph Sible Sep 8 '18 at 18:40
  • Yes, just the algorithm. Also, I'm asking just to understand what the best way to do this sort of thing is: clean way to let the user run my code and not be able to read it – tsotsi Sep 8 '18 at 18:49
  • I just got it to work the following way: 1. Put all code under users HOME folder 2. Remove read privileges 3. Put bash script that runs the code in /usr/local/bin – tsotsi Sep 8 '18 at 19:02
1

One common way to make sure users can't read the source code of something they are causing to run would be to write a service which acts on the user's behalf with the necessary privileges. Then give users a way to communicate with the server, such as a socket or a TCP port. At this point the code is no longer running in a context available to the user. Writing this isn't trivial, since you might need to consider for example users trying to use your service for privilege escalation.

  • Yes, that would work, thanks! One quick & dirty way to achieve similar functionality could be to let the user "schedule jobs" and then have a root background process or cron job actually run them? – tsotsi Sep 8 '18 at 23:13
  • Another partial solution is to compile the Python script – tsotsi Sep 8 '18 at 23:17
  • If you want to suggest solutions to your own question you can post them as answers. That makes it easier for others to rate and comment on them. – l0b0 Sep 8 '18 at 23:26
  • Sure! The above two comments are partial solutions and I just submitted a separate answer with a trick that solves the problem by editing the sudoers file – tsotsi Sep 9 '18 at 0:20
0

A solution that worked for me is the following:

Add the following line to /etc/sudoers:

user ALL = (root) NOPASSWD: /path/to/script

As the user, run the script as follows:

sudo /path/to/script

That way the script itself (and all subsequent Python scripts) are run as root but at the same time none of them are readable or writeable

  • Running code as root opens up a whole other can of worms. I would not recommend this method. – l0b0 Sep 9 '18 at 0:52
  • 1. Make sure no code run by the script is writeable by the user 2. In the actual bash script use full paths /usr/bin/python3 instead of python3. Would that be an exhaustive list of prerequisites to make this solution secure? – tsotsi Sep 9 '18 at 1:17
  • No. But this is getting very off topic. – l0b0 Sep 9 '18 at 1:38

Not the answer you're looking for? Browse other questions tagged or ask your own question.