Is there any way to insert an Environment variable into a Linux local machine from a website?I just want that when an user clicks on a button from a website,automatically to insert an environment variable into the user linux machine.I need to do this in any web language programming.
This is definitely not possible - for the same reasons that you can't open files in Javascript from the browser.
Another solution is to allow them to download a bash script and run it on their own. You will need to include instructions to run it, of course. (Don't forget to make it executable chmod +x)
As a side note, this is probably not a good idea in the first place. You could include literally anything in that bash script, and the user (assuming (s)he can't read bash) would just have to trust you. It is generally not advised to run random bash scripts on your computer or allow websites to make modifications to your environment variables.
Related
I've created a bash script that I'd like to share for other people to use
The script downloads video files, stores them in appropriate folders (which are essential to the app) and allows the user to cycle between them, using getopts so the user can send specific commands via flags
I've never done this before so I'm unsure of what "configuration" requirements I'd need to have so it works on other peoples computers. I want them to be easily able to download using homebrew or another package manager, automatically set up the required components and have them be able to use it
I know I have to create folders and a man page for them at the appropriate location. Does this require a makefile?
What other things should I be considering? My google search skills are sucking, so any links would be much appreciated
Package a precompiled busybox (https://busybox.net/downloads/binaries/latest/) next to your script, and use busybox functions only.
Within a tcl script, is there any way to do the command "sesu username" (or equivalent) to change the user the tcl script is running as?
For example, I run RunAnotherScript.tcl as user myusername (low permissions) and want it to sesu to user weblogic, because that user has the required permissions to run another script.
I'm a beginner at tcl... so the more information the better.
Probably the easiest thing to do is put the commands that are to be run as another user in a separate script. This also helps keep the logic between the low permission user and the high permission user separate. Then,
exec sesu weblogic -c RunWebLogicScript.tcl
Tcl does not include this functionality as a core command.
However, it is straightforward to write a compiled extension to add it in. A reference implementation of "setuid" can be found in the tclhttpd source
For part of a large university project I have built a large java based application. To make "installation" cleaner I am aiming to write a script to copy the jar to a hidden file in the users home directory then add a menu &/Or desktop launcher.
Since I do not know what platform the markers shall be using it seems sensible to make this generic so I was going to build a shell script and a batch file.
The shell script starts off simple, check the directory doesnt already exist, make it and copy the file accross.
Then it comes to making a launcher of some kind. I presume each desktop environment shall do things differently.
After 10 minutes with google it seems everything suggested is autotools but since I have no knowledge of this it seems a bit overkill.
Is there an easy way to achieve what i need?
Thanks
These days, basically all of the desktop environments uses desktop files. For the specification for those files, see the Desktop Entry Specification.
Normally, they're put in /usr/share/applications on the system. Those files are then read and used to construct the menu.
If you have the ability to write to the system /usr/share/applications directory, that's obviously simplest, but if you had that, you would probably be putting the JAR file somewhere other than a hidden directory in the user's home directory.
If not, the path that's supposed to be honored is ~/.local/share/applications. If you drop a desktop file in there, it should show up for the user. (This is somewhat newer; I don't think GNOME 2 supports, it for example. Older desktop environments had various special places for these files.)
Then, the problem basically reduces to figuring out what to write for the Exec line in the desktop file. (See the desktop files on your system in /usr/share/applications for some examples.) If you're lucky, you can get away with just sticking a java command in there, but the details will depend on your application.
really new to linux scripting so i figured i would ask rather than waste time pulling my hair out.
i have a simple script that backs up the contents of a folder on my linux box and moves it to S3 storage, i would like this script to create a zip file and password protect it without any intervention from me.
i got it down to
zip myarchive.zip /var/www/* -e
but cannot work out where i should put the password to stop it prompting me.
thanks
kris
Doing that is a security risk as it means your password will be written in cleartext in your script.
For this reason, zip refuses to work that way. It wants the input from the keyboard, not your script or a file.
I'm not aware of a workaround.
On the other hand, at least the zip in my Ubuntu distribution offers a -P password option which, I think, allows you to enter the password right on the command line. The documentation surrounds this option with the appropriate warnings.
You could also use the security features provided by the file system. This is indeed another story, but it does protect your information in most cases.
So I guess doing a chown and chmod on your archive after creating it will prevent unwanted users from accessing the file, if all you need is a file that can only be read by a certain group. The main advantage is that there's no need to memorize a password here.
I am creating a graphical installer that should run on Linux. Installing should consist of copying files to some places in /usr. Currently the installer is written in Python.
How can I escalate the privileges of my installer when I need to copy files? I looked at PolicyKit but
a) there doesn't seem to be a generic "install files" action-id for PolicyKit
b) of the action ids I can use, I don't think they are standard across distros
I also looked at PAM and I have code that uses libpam but I can't seem to do anything with it. After authenticating my user (by providing username and password) I don't have write access to /usr. I tried changing my user with os.setuid(0) after authentication but I get an error from the OS.
Also, strangely, it doesn't seem to matter what service I provide to pam_start. As long as the username and password are correct I can pass anything I want. I see I have /etc/pam.d/sudo. The below code is simplified, the password is correctly stored in a pam_conversation object and I do pass a handle object.
pam_start("my_user", "my_pass", "sudo_garbage_12345");
works just as well as
pam_start("my_user", "my_pass", "sudo");
That is, they both succeed.
As a last resort I can probably execute gksudo or kdesudo but I don't want to be tied to those programs. Requiring users to invoke my installer with sudo is a (very) last resort.
You might be better off wrapping RPM with a front end that takes the user options and invokes RPM to do the hard work. This also gives you infrastructure for managing dependencies and plays nicely with the existing package management system. If you need to run on a .deb based system (Debian or Ubuntu) you may also need to consturct a .deb and put some mechanism in the front end that works out which package management system is active.
Granting random users access to root privilege is generally viewed as bad form on Linux or Unix systems (or any multi-user system for that matter) as it is a significant security risk. However you do have the option of letting the user install it under their home directory (~/bin) if they don't have root access or sudo permissions that allow them to write to system areas. In this case you can require them to install it as root if they want to install in /usr/bin but permit them to install it under their home directory for their own use if they don't have root privileges.
For a graphical installer, stick with a graphical environment. Use gksudo or kdesudo if they are available, otherwise fail with an error dialog saying they need root. People (newbies in particular) will download your installer and double-click to launch it from their desktop, and you need a graphical way to ask them for their password. You don't want to pop open a terminal on them.
Given that, don't do sudo for them even if they are running from the terminal. Just output an error saying you need root and exit. If the user is already at the command prompt (like I most likely would be), I already know how to sudo or su myself into root if I want to do so. I promise you you will most likely ruffle some feathers if you attempt to make an experienced user root when they can do it themselves.
If you INSIST on doing a sudo yourself from within your installer, for God's sake please force a 'sudo -K' before you do to remove the previous timestamp. If you don't do this, and I have sudo'd recently, you will run your installer with me as root without my knowledge (since I don't expect that to happen). A 'sudo -K' will force a prompt that I can then decide whether I want to proceed as root or not.
The best way in this case is to use su within your program. Redirect inputs/outputs and you're good to go!