Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
My question is about permissions and ownership settings for my custom shell scripts and the custom shell script directory itself. This is only for security on my personal machine, but I'd like to know best practices for any situation.
My script directory is /usr/local/scripts/
Should I give myself write privileges to my own scripts? Or should root be the only one?
Should everyone else have read-only permission?
Should root have ownership over any of my scripts/directory?
I'm still learning UNIX permissions, so trying to wrap my head around the implications of certain files having certain permissions still eludes me to an extent. Thanks in advance.
First, I recommend you to put your unprivileged scripts (scripts that do not need to be executed as root) inside your home folder (it is a common practice to put them in ~/bin, some distributions even add this directory to your $PATH, so you can execute them from any directory). That way you do not have to write to a root-owned directory, avoiding the need of becoming root to edit them.
About execute permissions, almost always, if you have read permissions you will be able to execute it, either by copying to another location and giving it execute permissions, or by launching the interpreter with the script as first argument (eg. bash my_script.sh).
I see no problem in giving others read and execute permissions to my scripts, remember that they will be executed with the executing user's permissions, not yours. Anyway, if they have the knowledge, they will be able to write and execute them.
If you put scripts outside your home directory, they should be owned and only editable by root (they can be readable and executable by everyone). That way, if root executes it, it knows that no one else can have changed the file, so it is secure.
Should I give myself write privileges to my own scripts? Or should root be the only one?
I don't see a security reason not to give yourself write privileges - it is just inconvenient to manually maintain scripts in system directories. If these scripts are for personal use, it is best to keep your scripts somewhere in your home directory, probably ~/bin and then add that directory to the beginning of your PATH variable through your shell's startup script in your home directory. That way, you don't need any special permissions to test your scripts.
Should everyone else have read-only permission?
Unless you want to keep the contents of your script a secret, it should not be a problem to give others both read and execute permissions.
Should root have ownership over any of my scripts/directory?
The important thing is that other users must not have write access to the scripts. As long as the owner is you and you are the sole member of the group assigned to the file, you don't need to worry about security. It is just not convenient to have your scripts outside your home directory, but otherwise things should be fine.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I am making a project in linux which needs to shutdown the system when process is finished. How can it be done without the need to provide password?
If your program (e.g. in C, C++, Ocaml, ...) is compiled into an ELF executable you could make it setuid (then use seteuid(2), sync(2), reboot(2) syscalls, or better yet execve(2) on /sbin/poweroffor other commands). But be careful (be afraid of security holes, ...)
You'll need to code your program very carefully, and you'll need to be root to install your program with the setuid bit set (e.g. chmod u+s as root). But users won't need to be root to run the installed executable.
You should read Advanced Linux Programming (and carefully several man pages for important syscalls(2)). Please take time to understand the setuid mechanism, which is tricky and can be used dangerously.
And you could simply install and configure your system to start your program as root (e.g. by configuring your init or systemd, or some crontab, or some startup in /etc/rc.local etc etc etc ...)
Read also credentials(7) and capabilities(7)
On distributions with recent systemd, it is possible to shut down the system if no other user is logged in. This requires however a full-blown login session via systemd-logind, of which I don’t know whether you have it.
If your process lives in such an environment, you can call systemctl poweroff or systemctl reboot. The context of your process (running in a full blown login session, if no other user is logged in) will allow you to shut the system down.
If you use visudo and add
%group_name ALL=(ALL) NOPASSWD: /sbin/shutdown
you can use shutdown without providing a password.
However you will still need sudo.
But you could create an alias in .bashrc which replaces sudo shutdown now with shutdown
How to create an alias:
http://community.linuxmint.com/tutorial/view/891
of course this works with every other command as well
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I installed the shrewsoft vpnmanger on my linux (crunchbang kernel 3.2.0-4 amd64) the problem is, that somehow it can only be started as sudo. Can someone explain how i can fix this?
sudo /usr/local/sbin/iked&
How can I change the iked installation so that it is available for each user?
Thanks
It's just about the paths a normal user's shell search for commands. But normally it makes sense that those commands located in a sbin dir are not accessible by typing just the command's name. Those commands need access to protected resources that are only accessible by root.
But if you have the luck that you can gain the full rights by means of sudo you can simply create an alias via
alias iked="sudo /usr/local/sbin/iked"
and add it into your shell's resource file.
To make the full command accessible to all users by simply typing iked you can create a little bash script named iked with content
#!/bin/bash
sudo /usr/local/sbin/iked
and place it in /usr/local/bin.
Of course that implies an appropriate /etc/sudoers file and that the execute permission of iked is set.
try copying or symlinking in it in /usr/bin.
and see if it work for the user then, if it has a global log file (I don't know about this app so not one to comment) but assuming it has some log in /var/log/iked.log and its been written by root you will have permssion issues by another user, so chown it to some neutral group like users or something.:
Try here it may give you more info, I can see you could try:
/usr/bin/iked -d 4
But from what I read it does have a log in /var/log and yep that permission issue would be the primary issue specially if root was the first user to run this app.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I have recently purchased a dedicated server with apache on centOS. I want to understand the complete file structure in the server. I am accessing it through putty shell prompt.
What i need to understand is that how the files are stored and where. Like through WHM i am able to login to cpanel and create subdomains etc. And through ftp, i can put contents in that subdomain directory.
Now how do i access those directories for subdomains? How the individual website accounts are stored? I want to get a clear picture of the complete system through shell. I just now prefer using shell to view the file system hierarchy. any help would be really great.
Most/many Linux distributions adhere to a standard layout called FHS - File System Hierarchy Standard. That lays out some of the ground rules around where major things go - things like /etc for configuration and /var for things that, well, vary.
The most relevant thing you probably care about is that apache's config information is somewhere in /etc/httpd, the actual HTML files are in /var/www and the logs are in /var/log.
http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-filesystem-fhs.html.
How to list the contents of a package using YUM? will show you where the apache package puts things by default.
Note that all of this is just convention - if you install apache from source you can put everything where you like, but it may confuse other people that have to support your box.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Why are Linux file permissions still so primitive and is this likely to ever change?
Each file/dir can only have an owner and group. This seems to make the following things extremely difficult to implement:
How can you make a file read only and not delete-able, but still give that user permission to write to its directory?
How can you restrict directories to only certain users with out having to create a group for every possible combination of users required? And having done that its useless anyway because anyone who creates a file doesn't get it's permissions inheretted, so every user has to explicitly change the permissions on every file they make just so others can edit it.
I have found myself having to modify my programs to set the permissions of a file to the directory where it is saved to just to avoid user frustration.
How do you handle these sorts of things on desktop systems with non power users?
You can use the ACLs to have an advanced control on file and directory permissions.
An example (for Archlinux in this case) is here: https://wiki.archlinux.org/index.php/Access_Control_Lists
Have you tried using Access Control Lists ? see the setfacl command for an overview.
The issue of inheriting incorrect permissions is discussed at linuxquestions.org. Below is a summary of the proposed solution.
#mkdir tech
#chown root:tech tech/
#chmod g+s tech/
#chmod 0750 tech/
#setfacl -d -m g:techAdmin:rwx tech/
#setfacl -m group:techadmin:rwx tech/
The above will create a new directory tech which is owned by the tech group. The user group techAdmin will have access to read/write/create and tech group users will have read access.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I am new to Linux. I am interested in security too. I got to know from one of my friend that it is possible to get into root shell after login as a normal desktop user. I don't know how to do it. I only know its possible after exploiting some services.
When I search for the above topic, I come to that, first we need to find out SUID files, which are the executable files having special permissions. I used 'find / -perm +4000' command to get such files list.
I don know what to do after that and get into root shell. I need to find out such issues in my OS and need to patch it. Could you please help me?
After you get your list of root suid programs (this is just one of many starting points when trying to get root on a system) you have to find if any of them are vulnerable to buffer overflows (you can start searching the CVE database for their names) and get a shell payload to be executed when the hole is exploited (so you can get a root shell).
There are many resources on the topic and by googling for "buffer overflow" you'll get to them.
There's no generic way to do this; it depends on what vulnerabilities exist on the system you've logged into, and that can vary from machine to machine. You need to look at what version of the OS is running, what vulnerabilities are known in that OS version, and which patches haven't been installed on the machine in question.