I have installed a ruby script (script.rb) on a Linux system that 'requires' another file (required.rb) with a bunch of custom methods.
I do not want to let my users read required.rb.
If i remove read access (i.e. chmod 600 required.rb) and then try to run my script as a user I get the following error:
no such file to load -- /etc/required.rb
Is there away to allow ruby to read this required file but stop users from seeing it?
Whether a process can read a file is governed by the effective UID of the said process. If you change permissions of the file, then processes by the user (including the ruby process) cannot read it.
One solution is to make your ruby interpreter owned by someone else and then make it setuid but this will give it the power to read these "protected" files regardless of what script it runs. In short, don't do this.
An other option is to keep your data somewhere other than on the file system and then use a separate authentication system for that.
The right way in my opinion is to have all the methods in your script but use some kind of a AAA harness that restricts access to methods you don't want the user to run. You can then use any AAA backend to authenticate your user (LDAP, password file etc.).
Related
I am writing a service/module in Go for a bigger system and I'm having trouble with permissions on macOS. I am hoping anyone here has any experience with this.
This module is using network interfaces in macOS (read+write), and therefore needs admin/root permissions. The module is also in the form of a process which will communicate with parent process through stdio. Since it needs root permissions, I have tried wrapping it in AppleScript: do shell script [...] with administrator privileges, but osascripts does not return the output in real time, instead it returns the stdio output when process has exited. I need the stdio output in real-time, and it is annoying to write the password every time the module is started.
So that leaves me with the question of how I can request permissions for network control in Go. Like the popup you see on some programs "wants to use your microphone", only with network permissions. Is this possible?
If not, how can I solve this issue of needing root permission for a real-time module in macOS?
I found a viable solution; launching the script with sudo -S , and asking the user for root password through my own GUI service. As long as the root password isn't stored anywhere, it should be fine security-wise.
Being fairly new to the Linux environment, and not having local resources to inquire on, I would like to ask what is the preferred method of starting a process at startup as a specific user on a Ubuntu 12.04 system. The reasoning for such a setup is that this machine(s) will be hosting an Input/Output Controller (IOC) in an industrial setting. If the machine fails or restarts, this process must boot automatically..... everytime.
My internet searches have provided two such area's to perform this task:
/etc/rc.local
/etc/init.d/
I ask for the specific advantages and disadvantages of each approach. I'll add that some of these machines are clients and some are servers, but all need to run an IOC, and preferably in the same manner.
Within what ever method above is deemed to be the most appropriate, a bash shell script must be run as my specified user. It is my understanding all start up process are owned by root. So I question if this is the best practice:
sudo -u <user> start_ioc.sh
If this is the case, then I believe it is required to create a file under:
/etc/sudoers.d/
Using:
sudo visudo -f <filename>
Where within this file you assign the appropriate rights and paths to the user. Most of my searches has shown this as the proper format:
<user or group> <host or IP>=(<user or group to run as>)NOPASSWD:<list of comma separated applications>
root ALL=(user)NOPASSWD:/usr/bin/start_ioc.sh
So for final additional information, the ultimate reason for this approach, which may also be flawed logic, is that the IOC process needs to have access to a network attached server (NAS). Allowing root access to the NAS is I believe a no-no, where the user can have the appropriate permissions assigned.
This may not be the best answer, but it is how I decided to complete this task:
Exactly as this post here:
how to run script as another user without password
I did use rc.local to initiate the process at startup. It seems to be working quite well.
I am currently making a CLI tool gem that downloads files from some service and saves them to a specified folder.
I was wondering, what would be the best way to store user settings for it?
For example, the folder to download the files to, the api access token and secret, that kind of thing.
I wouldn't want to ask a user for that input on every run.
I would read the API stuff from environment variables. Let the users decide if they want to enter it every time or set the variable in a .bashrc or .bash_profile file.
And I would ask for the download folder every time.
I understand that three types of permissions to a file (read, write, execute) can be set independently, hence there are eight possibilities per file per user (superuser, group, normal user). Based on this fact, I had believed that a superuser can set a certain script file (in my case, a Ruby file) to be executable but not read/writable to a normal user. But in the context of this question, Wayne Conrad and Linuxios noted me that a script cannot be run by a user who does not have read permission to that file.
Why is this the case? If a user needs read permission in order to execute it, then why is it possible to set the three permission types independently? Particularly, what does it mean to set a script file permission to executable but not readable?
Is there some way (hackish, it may be) to make a script file runnable but not readable from a certain user?
In the case of script files (python, perl, ruby, shell, etc.), the file itself is not "executed" in the usual sense. Instead, the user's shell opens the file as if to fork/exec it, spots the shebang and then arranges to have the requested interpreter started, and passes the rest of the file to it. If the user doesn't have read permission on the file, then clearly the user's shell can't read it, and this setup fails.
This isn't the case with binary commands, which can indeed be set with no read permission, and will still work.
I'm using a build script that calls Wise to create some install files. The problem is that the Wise license only allows it to be run under one particular user account, which is not the same account that my build script will run under. I know Windows has the runas command but this won't work for an automated script as there is no way to enter the password via the command line.
This might help: Why doesn't the RunAs program accept a password on the command line?
I recommend taking a look at CPAU.
Command line tool for starting process
in alternate security context.
Basically this is a runas replacement.
Also allows you to create job files
and encode the id, password, and
command line in a file so it can be
used by normal users.
You can use it like this (examples):
CPAU -u user [-p password] -ex "WhatToRun" [switches]
Or you can create a ".job" file which will have the user and password encoded inside of it. This way you can avoid having to put the password for the user inside your build script.
It's a bit of a workaround solution, but you can create a scheduled task that runs as your user account, and have it run regularly, maybe once every minute. Yes, you'll have to wait for it to run then.
This task can then look for some data files to process, and do the real work only if they are there.
This might help, it's a class I've used in another project to let people make their own accounts; everyone had to have access to the program, but the same account couldn't be allowed to have access to the LDAP stuff, so the program uses this class to run it as a different user.
http://www.codeproject.com/KB/dotnet/UserImpersonationInNET.aspx