I have a .jar file that needs to be run as an admin user but I want to execute it from a standard desktop users account (eg. they are not admin and do not have sudo priviledges)
I have tried using the visudo file with nopasswd but from what I can see this only applies to admin users
I dont want to have to enter an admin password
Any help appreciated!
If you need to be an admin but are no admin, then I guess you just can't.
If you don't actually need to be an admin, then java -jar $jarfile should do the trick.
If you need to be an admin but don't care about running on the actual desktop OS, then you might use a container (Ubuntu ships LXC, for example) or a virtual machine (look at Virtualbox), where the user can be an admin without actually being an admin on the underlying OS.
The simple answer is - its not possible.
Your "standard" users just don't have execute permission for that file.
This is one of the basic security principles of operating systems in general.
You can check the permissions of your file with ls -l /path/to/your/file.
And the only legal solution is to set the executing permission for your "standard" users.
Related
Im using cent os 6 for my work. For educational purposes I want to add user to the cent os by only editing configuration files.I know we can easly add user by useradd command and change their password using passwd command. But I need to use exactly above mentioned way. To do this first I need to understand what are the files I have to change
By searching I found that following files are responsible for handling user
/etc/passwd
/etc/group
/etc/shadow
/etc/gshadow
What I did is first I add the user using useradd command and then study the strings that commands created in above files. And then I try to replicate it with manually editing files using VI editor. After I replicate every line of string I make a directory for my new user in /home. the I reboot the VM and try to login as manually created user. I can log in without any problems but the terminal showing bash-4.1$ instead of my username. but when I use whoami terminal prints my username correctly.
My question are
Is there any other files do I need to modify to add user successfully?
By adding user manually what are the functionalities that user lost ?
How to create MD5 hashed password for manually created user ?
I know to you this is may be little bit odd. but I need to do this exactly this way. If this question is inappropriate please let me know without down voting
thanks
Those are the essentials, obviously you'll need to create a home directory for that user with proper permissions, as well as any additional user specific resources.
You might want to also read up on the Pluggable Authentication Module or PAM. This provides increased authentication functionality to Linux beyond passwd, group, shadow files.
Also check out the GETPWNAM() system call.
=D Enjoy the Posix!
Serverfault on password hash creation below.
REF: https://unix.stackexchange.com/questions/81240/manually-generate-password-for-etc-shadow
When I install Cygwin, the default location is c:\cygwin and after I open a Cygwin terminal, it creates my home folder in C:\cygwin\home\ which the Everyone group has read access to by default. So, if I create a diary in vim and save it to my profile, all users of the computer I'm logged on to can read my diary. Obviously this is not the default option for normal Windows profiles, so I'm wondering what the logic is behind Cygwin's default home directory permissions, so I can use it the way it is meant to be used. Thanks!
There are differences between the permission structures of windows and cygwin.
You can protect your diary by specifying its permission in windows using right click.
You can then check its permissions in cygwin using:
ls -l diary.txt
chmod 0600 diary.txt
ls -l diary.txt
Then login the same machine as a different (test) user and see if you read the file under windows, and in cygwin.
For people interested in this topic, it probably goes back to a setting called UMASK on linux, which specifies default permissions for new files. The default value of "022" means "take away no permissions from the owner, and take away write permissions from the group and the rest of the world" which means that file owners have full access, everyone else has read access.
They say it's to make it easier to share files with other users. I say it's obvious that this logic predates times when we had web browsers and other tools capable of saving passwords to disk.
Is there a way that I can secure the webapps folder in Tomcat from direct access from a system user? In other words, I dont want a user to logon to the server machine and access the webapps folder. However, id still like the contents of the webapps folder to be served accordingly.
Would a soloution such as TrueCrypt to encypt the folder work? Or something like Windows admin rights? However, id still need a user to logon to the server machine to start and stop tomcat (bin folder) but not have access to the webapps folder.
Update Feb 15 '11: Yes, it's to stop someone logging onto the server machine and deply/undeploy. Since I'm going to be using a windows machine, I will probably restrict access to the tomcat folder and create an exe on the desktop to start and stop the services.
I am not sure what you mean by "access webapps folder", I will assume this means user can deploy/undeploy webapps and start/stop Tomcat. In Unix this can be doable as follows:
create a user for Tomcat. Change umask so all created files are only readable by this user and no one else, similar for directories.
create a user (e.g. system) that will be stopping/starting Tomcat.
give sudo rights for user system just to be able to start/stop Tomcat. You can, for example, externalize catalina.sh start and catalina.sh stop scripts somewhere in /usr/local/bin and give sudo access to those.
create a script that takes yourwebapp.war and copies to $tomcat_home/webapps or invokes relevant Tomcat manager command (for deployment/undeployment). Again, give sudo rights just for that script but otherwise change it's mode to 700 so it is not even readable by system user.
My application is not supposed to perform any administrative tasks, so I want a normal User account to be able to run it. Only thing is, my application reads from and writes to a database file; if the user running Windows 7 (Or Vista) installs my app in drive C, the drive's default permission set configuration doesn't allow my app to write data.
How can I allow my app to write to C:, without requiring full administrative privileges?
If the database file exists at install time you can just grant the user write access to the file as part of the installation process (ordinary users do not have this permission by default). If the file needs to be created by the program the user running the program will need modify permissions on the c drive, which is not something that I would recommend.
I'd suggest storing your db file in Documents and Settings / App data / your app / directory. It exists specifically for this purpose. Writing to C:/Program Files is not so good practice. If that's possible in your case, that is.
You need to open UAC (User Account Access) and set security slider to the bottom. Then you can access drive C: as you did in windows XP.
I decided to modify directory permissions in the setup process, so I created an .exe file that changes the permissions of its start-up path, and gives all users access to that path. I simply included that .exe file in my deployment project, and created a Custom Action that would run the file in the Commit phase of installation.
Because the setup asks the user for administrative rights when it is being installed, my .exe also enjoys administrative privileges and can modify the permissions of the installation directory.
In my .exe, I used a Process instance to run the ACL utility shipped with Windows (icacls.exe) as follows:
ICACLS.EXE [TargetDir] /T /C /grant Users:F
(Make sure that [TargetDir] doesn't end with a "\" or the call will fail.)
This gives all users full control access to the target directory.
I could also write .NET code and change directory permissions manually, but I'm a little lazy!
You may however want to inspect your environment conditions thoroughly so that what you do wouldn't become a security hole in your environment; but this was suitable for me.
I hope this helps others who faced the same issue.
The user by default should have write permissions to drive C:, if not, then you will need to change the directory you read from and write to, to the executing directory (C:/Program Files/Your App/) rather than the root of C:
You can get this by
String Path = Path.GetDirectoryName(Application.ExecutablePath);
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!