My problem is about using the source command for everyone logged in.
Let's say I have a file with the content:
#!/bin/bash
alias ha='echo test'
Now if I source it and write ha, I'd get the message test.
Now what if there's someone else logged in, and I want it to be sourced for his account? Can you write something like source (username) (filename)?
Provided that other uses have read permission to your script, and read permissions to its directory and parent directories, they can source that file. Assuming your user name is "thesourcequestion", and you are keeping the alias file (let's call it alias ) in your home directory, other users can source it with the following command:
source ~thesourcequestion/alias
Or just (same thing):
. ~thesourcequestion/alias
Incidentally, some shells only accept the source keyword (like c-shell IIRC).
If you are the admin of the box, consider the solution presented here:
https://askubuntu.com/questions/610052/how-can-i-preset-aliases-for-all-users/986053
In short, there are system files that can be modified that will create the alias for users. The alias will be available to them next time they login.
Don't overlook the part of my answer about providing permissions to your file. For example, you can give read permissions to the file this way:
chmod a+r ~thesourcequestion/alias
The above syntax adds (+) the read attribute (r) to all (a).
Related
I need help creating a custom command in the linux terminal, for this I have the following problems, I want to do:
copy file path: /test /file
How can I insert a user "input" in bash format so that later the terminal understands the file I want to copy and the path?
Sorry if I don't explain myself very well ... I'm new ...
First of all, do not worry about being new. We are all here to learn and help each other!
Assumption
From what I understand, you would like to create a Bash script which accepts user input specifying both the filename and the destination path for the file to be copied to. The code below does exactly that but note that it does not have the auto-complete feature when accepting user input.
Solution
script.sh
#!/bin/bash
# ask user for file name to be copied
read -p "Name of the file to be copied:" filevar
# ask user where they want the file to be copied to
read -p "Destination path:" pathvar
# does the copying
cp -- "$filevar" "$pathvar"
Usage clarification
In case you are not sure how to run the script, I will give you an example scenario. Open your terminal and make sure you are in your Desktop directory. To run the script, enter ./script.sh. Then enter the file name to be copied, press Enter, and then enter the destination path. In your case, it is test (assuming you have a test folder on your Desktop). Press Enter one last time and the file will be copied to the destination.
Just let me know if you were expecting something different as I could not comment on your post to get more clarification due to my low reputation.
I created this simple script to allow the user to remove files created by the web server in his home directory without giving him "su". Both scripts are set with "chmod 4750".
The craziest thing is that they DID work and now they don't. Here's the scripts:
#!/bin/bash
# Ask for directory to delete
echo "Enter the file or directory you would like to delete, the assumed path is /home/user"
read DIRECTORY
rm -rf /home/user/"$DIRECTORY"
echo "Deleting /home/user/$DIRECTORY ..."
exit 0
2:
#!/bin/bash
# Reset permissions
echo "Resetting the ownership of the contents of /home/user to user."
chown -R user /home/user
exit 0
I will make them a little more advanced and work for multiple users but right now I cannot even get the simple version to work. It works when run as root of course. It used to work when run as user 'user' but now it doesn't. I get this:
user#dev:/home/user$ delete.sh
Enter the file or directory you would like to delete, the assumed path is /home/user/[your input]
test-dir
rm: cannot remove ‘/home/user/test-dir/test-file’: Permission denied
Deleting /home/user/test-dir ...
and
chown: changing ownership of ‘/home/user/test-dir’: Operation not permitted
What can possibly be the problem?
-rwsr-x--- 1 root user 291 Nov 6 05:23 delete.sh
-rwsr-x--- 1 root user 177 Nov 6 05:45 perms.sh
There is a pretty comprehansive answer at https://unix.stackexchange.com/questions/364/allow-setuid-on-shell-scripts
Bottom line is that there are two main points against it:
A race condition between when the Kernel opens the file to find which interpreter it should execute and when the interpreter opens the file to read the script.
Shell scripts which execute many external programs without proper checks can be fooled into executing the wrong program (e.g. using malicious PATH), or expand variables in a broken way (e.g. having white space in variable values), and generally it has less control on how well the external programs it executes handle the input.
Historically, there was a famous bug in the original Bourne shell (at least on 4.2BSD, which is where I saw this in action) which allowed anyone to get interactive root shell by creating a symlink called -i to a suid shell script. That's possibly the original trigger for this being prohibited.
EDIT: To answer "How do I fix it" - configure sudo to allow users to execute only these scripts as user root, and perhaps use a trick like in https://stackoverflow.com/a/4598126/164137 to find the original user's name and force operation on their own home directory, instead of letting them pass in any arbitrary input (i.e. in their current state, nothing in the scripts you include in your question prevents user1 from executing the scripts and passing them users2's directory, or any directory for that matter)
I want to index some files and keep a registry as part of a utility I am writing in BASH. So, my tool would go to a massive directory and write some essential information about each file it finds there to another file that I would like to call "myregistry." The file would only be rewritten if the user asks it to - since going through a large file structure and "indexing" it this way would take considerable time.
I want this file to not show up when the user does ls in the directory where it is contained. In addition, I want the user to have no privileges with it at all - the user should not be able to open it up on vim or anything, not even to just look at it.
However, if the user executes my script again, I want the user to have the option of getting some information out of the file from there. I also want the script to have the permissions to look at the file and add or delete things from it, if the user prompts it to. But the user should not be able to do anything to it directly.
How can I do this? It would require using chmod but I have no idea how to put it together.
I'm thinking:
# Enable write permission
# Do Something - ensure that no one else is writing to this file
# Disable write permission
On Unix, you're more or less on an equal footing with other processes that run under the same user. Whatever you can do, they can do. If you can hide and unhide something, so can they. Interpreted scripts need read permissions to run, so it's not like you can hide any secrets in your executable. If you can however, distribute your software as a binary, you'll be able to run without being readable. Then you can hardcode a secret into the binary and use it to encrypt and decrypt files. Users will be able to run your binary, but only the superuser will be able to get the secret and decrypt your registry. That's real security (against regular (nonroot) users) (especially if you manage to create and embed the secret at installation time).
Playing with dotfiles and permissions won't fool any advanced user.
Something like this work? write_index and read_index are your work.
cd massive_dir
TFILE=$(mktemp --tmpdir=.)
write_index >$TFILE
mv -f $TFILE .index
chmod a-rw .index
To read
chmod +r .index
read_index .index
chmod -r .index
Note that no locking is needed because of the temp file. mv is atomic.
I have a unix shell script file whose owner is "xyz" when run deletes some specific files.
I want to trigger this script to delete files in some other directory where the owner for the files to be deleted is different from the owner of the script. Is this possible? Is this possible to run this script as different user so that it can delete those new files?
EDIT : I use Autosys to periodically trigger this script.
You can chmod the files that need to be deleted first if you have sufficient rights. Afterwards your script, no matter what user it executes, will succeed.
Examples : http://en.wikipedia.org/wiki/Chmod
Usually you use sudo for that:
sudo -u ANOTHER_USER /path/to/the/script.sh
However, your current account needs proper permissions to do so. You can configure those permissions using the file /etc/sudoers.
You'll find a ton of articles out there how to use sudo. This for example: http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:Ch09:_Linux_Users_and_Sudo
I have made a script for installing a control panel.
I've uploaded the script to a server so people can wget it to their machines.
The only issue is that you have to chmod it after download. Is there a way to remove this step? How would I go about keeping 755 perms on the downloaded script?
When a user downloads the file, the file will automatically get some default permission. In UNIX, each user will have a default set of permissions which apply to all files created by that user, unless you explicitly set it to something else.
This default is called the umask, after the command used to change it. It is either inherited from the login process, or set in the .shrc or .login file which configures an individual account, or it can be run manually.
Typically the default configuration is equivalent to typing 'umask 22' which produces permissions of:
-rw-r--r-- for regular files, or
drwxr-xr-x for directories.
In other words, user has full access, everyone else (group and other) has read access to files, lookup access to directories. As you see above, the execution access is not default for files.
Hence you need to explicitly change it.