I'm trying to make a simple c-shell like program on C (for Linux) that will execute scripts.
I need to read a script file in order to execute it, but how can I read it if it has only execute permission, and no read permission?
In short,
A binary file you can execute with only execute permissions.
A script is a text file, so you need read permissions.
So, you would need to play some games with group ownership, sudo, or similar.
Yes, you need read permissions to execute script.
However, I want to mention one possibility for another_user to run script without having r permission on the file.
You can allow somebody to execute somescript with sudo as another_user that have an r+x access to file.
However, you should have an access to /etc/sudoers (i.e., to be root, or ask superuser to add the record from below to etc/sudoers)
# Run script as the user 'another_user' without asking for password
somebody ALL = (another_user) NOPASSWD: /usr/bin/somescript
Solution found at
https://unix.stackexchange.com/a/77538 and
https://stackoverflow.com/a/21309969/1566267
You don't need read permission in order to execute a file.
In fact, if you have read permission, but not execute permission, you can't execute the file.
The execute permission allows you to ask the system to execute the script file.
Try with:
system("script.sh");
in order to execute a script (in the example script.sh).
You could also use:
execve("script.sh");
That would run the script replacing your script with the one in the specified script keeping the same pid as your script (as shown here)
The classic way of doing this is to make the wrapper C application setuid root. Root can read everything, regardless of permissions. That comes with a whole bunch of warnings though. Make sure that you're not closing a small security hole by opening a much larger one.
Related
I have a SAS code which works flawlessly when I first open the program and run the code interactively. However, if I try to run it as a batch file or execute it from the command prompt using the -sysin option, it doesn't run and I don't know why.
Part of the reason might be that when I run SAS, I receive this dialog box which I need to manually close:
Screencap 1
When I try to choose the option "Do not show this dialog box again" it doesn't work, and it shows the dialog every time I open SAS. This may be because my registry and profile files are corrupted:
Screencap2
Would this be the reason why? If I run the program interactively after closing the dialog box, the program run just fine. I tried to follow some steps to repair the registry and profile files, but it didn't work. Is that what I should focus on, or is there likely another reason it won't run in batch?
Thanks for your input!
edit: I was able to get the program to run from the batch file, but I get the following errors about permissions in the log file:
ERROR: Insufficient authorization to access //destinationonselecteddrive
NOTE: The SAS System stopped processing this step because of errors.
NOTE: PROCEDURE PRINTTO used (Total process time):
real time 0.01 seconds
cpu time 0.00 seconds
I do not have these issues with insufficient authorization when I run the program interactively, only in batch mode. Could it be a metadata issue?
You have to check with which profile your batch is running. When run interactively it may (and it will normally) use a different profile than the one you are using while running interactively. That means different user and password. You can check in the management console (or ask your administrator to check).
It sounds most likely like there is a problem with the user profile. At my old job I ran into problem with the profile when I ran concurrent SAS sessions. I had to set my user profile to read only using the RSASUSER option (SAS instruction here). If that is not the issue try creating a new profile catalog in a new location and then adding the -SASUSER option with the new location (SAS info on how to do that).
I need to create a directory in /var/log using a C program which does NOT run with superuser rights.
This linked question didn't help me!
I understand that the file permissions of /var/log does not allow us to write in it nor do I want to change it.
I use mkdir() to create the directory which fails for obvious reasons.
So, is it possible for a normal (with no root rights) C program to create a directory in /var/log?
My goal: To create a directory using a C program in /var/log without changing the parent's file permission. Should I run my program as root? But I would prefer not to.
Kindly help.
TIA
You cannot programmatically overturn the filesystem's access control.
What you could try to do instead is to use an existing logging mechanism that is provided by the system. For example, journald that comes with systemd allows for per-user logging.
If your program runs as a user, it should only use the user's home directory to store files, wether it being configuration or logging. Think about it this way: What happens if several users want to use your program at the same time?
If your program really is a system daemon, have a look at other software that runs under their own user. They could either have their own logging directory be prepared by the init script that calles them (running the daemon itself as a different user), or they purge their priviledges during startup. An example is httpd, which needs root priviledges to listen on port 80.
I got a batch file that will run a c++ program and output to a file with ">" redirection. This file is to be run by task scheduler.
I found out that when the batch file is ran from task scheduler, it claims "access is denied". The batch file runs fine until it reaches that ">" redirection part. (I see that the whole batch can run finely without ">") I have tried running the task scheduler as an administrator as well, but I still got "access is denied".
Is there a way around this?
For those who can't write file into the relative path.
Try go to property of the task.
property > action > edit your action.
Change the "Start in" to your EXE　working path.
There may be quite a few reasons of it, first check below points:
Check whether the user who has scheduled batch script to run in Task
scheduler has admin access on the system or not.
Give that user full Share/NTFS permissions on the "RedirectedFolders" and all of the sub
folders as well.you can manually propagate all permissions down to the folders.
The user should have read and write
permissions along with full control to the "RedirectedFolders" .
I was wondering, I am writing a program in C, and I writing the output from my program to a csv file. This works locally, and I can create and update the file with no errors.
But on the server, where I need to store the file - I do not have permissions to write to that file/directory. Is there a work around for getting around the permissions problems?
Well, you can run your program as a more authorative user, such as root.
There is no simple way from the program itself to just ignore the operating system's security model, that would make it quite pointless.
Note that if you're not the administrator on the server, you're likely not even allowed to run programs as root.
Finally, writing C programs that manipulate files and directories and then running them as root on a server is a fine way of shooting yourself in the foot. Be careful.
I have a written a C program that creates a file "abcd.txt" and write some data into it. I was executing my code by logging with a username"bobby" and so the file abcd.txt was created with owner as bobby.
But my task is, even though I execute my code with some username "bobby", the file should always be created with owner as root. Can someone help me by saying how this could possible?
As a general principle you need your effective uid (euid to be root) either when you are are writing the file or when you perform a chown(2) on the file.
If you are doing this under Linux then there are linux specific methods that you can use.
Generic Solution
Without availability of sudo
This is the old UNIX DAC approach, it's fraught with peril. It assumes that you do not have something like sudo installed or cannot install it.
Your executable should be owned by root and have the executables setuid bit set.
Process
You should use seteuid () to drop your privileges from root to bobby for most of the operation, including writing. When you are done, bring your privilege level back up to root using seteuid(0) and perform a chown() (or fchown on the fd) on the file to change its ownership to root.
some basic safety
For safety set it up so that your executable is owned by root:safegrp where 'safegrp' is name of a group unique to users who are allowed to execute this file (add bobby to safegrp) ; and ensure that the setuid executable's mode is 4510 ;
With availability of sudo
If sudo is available on your system then follow the same process as above for dealing with privileges within the executable but DO NOT set the file mode to setuid, have safegrp added to sudoers for this executable and now bobby can run it with sudo /your/bin/prog
Linux specific solution
POSIX.1e
It is possible to have tighter control over the file use POSIX.1e capabilities support. In your case you wish to grant SYS_CHOWN to your program;
For security reasons, I would probably set that up as a COMPLETELY separate binary or a sub process and still use sudo and perform appropriate dropping of privileges.
linuxacl[ACL Using Access Control Lists on Linux] has excellent tutorial on this topic
SE-Linux
You can use Mandatory Access Control to limit the access to such a dangerous binary but SE linux is a pain to configure :^) although a possibly a good approach
You probably don't want to run your program as root, unless you really have to. Perhaps run "chown" from a shell script after running your program? Or, you can use chown(2) from a program running as root (or with equivalent capabilities, on linux).
Use the chown() method. There are probably more authoritative links, but this one is nice since it includes the calls to getpwnam(). I've done all of this in the past, but unfortunately I don't still have the code (it's owned by IBM).
http://manpages.courier-mta.org/htmlman2/chown.2.html