I am using crontab to run a java code on a linux server and I want to log all messages and exceptions thrown by this code to a file inside /var/log/myapplog/ directory . I have already written the logger class.
But i want to make sure that only this piece of code may create files and write to files inside this directory. Is there a command for this instead of giving write permissions to all (chmod 777) ?
Thanks
The surest way is to run the program as the only user that may write to this directory. Make a user myapp, run chown myapp /var/log/myapplog and chmod 755 /var/log/myapplog (or 700), and use su in the crontab to give the program the proper permissions.
If the program needs different permissions, you might consider splitting the logger out into a different process.
Related
On this particular Linux server, we have a directory on which people can add certain files and we want those files to be owned by a particular user, editable by a specific group, and not viewable to public. Right now, what I have to do is to occasionally run sudo chown this_user:that_group /foo/bar/*.ext; sudo chmod 750 /foo/bar/*.ext from the command line. I would prefer if I could turn this into a command-line program that other users could invoke, including those who don't have sudo access. Imagine a program called /usr/bin/fixpermissions which would run the above chown and chmod commands and return a success message.
How should I write this script so that it wouldn't ask for a password for the sudo part? And how can I make it available to other users (is putting it in /usr/bin/ sufficient or appropriate)?
That's not so much a question of "How to write the script", but rather of "How to make it usable via sudo".
The canonical location for the script would be /usr/local/bin ...
To achieve the "execute as sudo w/o password" I'd create a separate sudoers file:
sudo visudo -f /etc/sudoers.d/fixpermissions
with the following content:
%group ALL = NOPASSWD: /usr/local/bin/fixpermissions
Obviously adjust names of files and groups to match your personal preferences and existing setup.
Careful with creating the sudoers file above w/ other means than visudo - you might end up locking yourself out of the box if you save a file with syntax errors (visudo will check it for validity on exit and prompt you to fix if it's borked).
i have script that is owned by root in a directory owned by root. part of the script is to make a directory that will hold the inputs/outputs of that script. i also have a sim link to that script so any user can run it from anywhere. i don't use the temp directory so this info can be used as logs later.
Problem: when a user tries to run the script they get an error that the directory cannot be created because of permission denied.
Questions: why won't the script make the directory so root owns it independent of what user runs it? how can the script make the directory so root owns it instead of the user that ran it? only the script needs this info, not the user.
Additional info:
the directory is: drws--s--x.
the script is: -rwxr-xr-x.
(if you need to know) the line in the script is simply: mkdir $tempdirname
i am matching the permissions of other scripts on the same server that output text files correctly, but since mine is a directory i'm getting permission errors.
i have tried adding the permissions for suid and sgid. suid sounded like the correct solution since it should make the script run as if it were run by the user that owns the script. (why isn't this the correct solution?)
i would like any user to be able to type in the sim link name, that will run the script that is owned by root in the directory that is owned by root, and the directories created by that script will stay in its own directory. and the end user has no knowledge or access to the inner workings of this process. (hence owned by root)
Scripts run as the user that runs them; the owner of the file and/or the directory it's in are irrelevant (except that the user needs read and execute permission to the file and directory). Binary executables can have their setuid bit set to make them always run as the file's owner. Old unixes allowed this for scripts as well but this caused a security hole, so setuid is ignored on scripts in modern unixes/Linuxes.
If you need to let regular users run a script as root, there are a couple of other ways to do this. One is to add the script to your /etc/sudoers file, so that users can use sudo to run it as root. WARNING: if you mess up your /etc/sudoers file, it can be hard to recover access to clean it up and get back to normal. Make a backup first, don't edit it with anything except visudo, and I recommend having a root shell open so if something goes wrong you'll have the root access you need to fix it without having to promote via sudo. The line you'll need to add will be something like this:
%everyone ALL=NOPASSWD: /path/to/script
If you want to make this automatic, so that users don't have to explicitly use sudo to run the script, you can start the script like this:
#!/bin/bash
if [[ $EUID -ne 0 ]];
then
exec sudo "$BASH_SOURCE" "$#"
fi
EDIT: A simpler version occurred to me; rather than having the script re-run itself under sudo, just replace the symlink with a stub script like this:
#!/bin/bash
exec sudo /path/to/real/script "$#"
Note that with this option, the /etc/sudoers entry must refer to the real script's path, not that of the symlink. Also, if the script doesn't take arguments, you can leave the "$#" off. Or use it, it won't do any harm either.
If messing with /etc/sudoers sounds too scary, there's another option: you could "compile" the script with shc (which actually just makes a binary executable wrapper around it), and make that setuid root (chmod 4755 /path/to/compiled-script; chown root /path/to/compiled-script). Since it's in a binary wrapper, setuid will work.
I would like to know what is the best, correct and recommended way of doing chown and chmod to website files and folders.
I recently started working on linux and I have been doing it in the site root directory like the following:
sudo chown www-data:www-data -R ./
sudo chmod 775 -R ./
I know it is not the best way. There is a protected folder which should not be accessible with browsers and should not be writable, so I did the following to protected folder:
sudo chown root:root -R protected/
sudo chmod 755 -R protected/
Is it correct? If anything can be improved please let me know.
Read your command again. What you are saying is "make everything executable" below these directories. Does an HTML or gif to be executable? I don't think so.
Regarding a directory which should not be writable by the webserver. Think of what you want to do. You want to revoke the right to write a directory from the webserver and the webserver group (and everybody else anyway). So it would translate to chmod -w theDir. What you did is to tell the system "I want root to make changes to that directory which shall be readable by everybody and the root group". I highly doubt that.
So I would suggest having the directory owned by a webserver user with only minimal read access, it should belong to a group (of users, that is) which is allowed to do the necessary of the modification. The webserver does not belong to that group, as you want the outside world to be prevented from making modifications. Another option would be to hand over all the directories to root and to the editor group and modify what the webserver can do via the "others" permission group. But what to use heavily depends on your environment.
Edit:
In general, the "least rights" policy is considered good practice: give away as few rights as possible to get the job done. This means read access to static files and depending on your environment php files, read and execute rights for cgi executables and read and execute rights for directories. Execute rights for directories allow you to enter and read it. No directory in the document root should be writable by the webserver ever. It is a security risk, even though some developers of bigger CMS do not seem to care to much about that. For temporary folders I would set the user and groups to nobody:nogroup and set the sticky bit for both user and groups.
I'm creating an app for the iPhone (Jailbreak). Said app modifies this directory (among others) "/Ringtones.PQNYRJ/", trying to create a ringtone file. The thing is that I've tried it every possible way and I can't get it to work. I've followed the Cydia's documentation and I've made a file with the same name as the app but with a shell script to execute the binary (renamed with an underscore).
dir=$(dirname "$0")
exec "${dir}"/MyTones_ "$#" 2>>/tmp/MyTones.log
I've set the proper permissions (or so I think)... I've based them off of Cydia.app permissions and all I got back is:
AVAssetExportSessionStatusFailed:
Error Domain=NSURLErrorDomain
Code=-3000 "Cannot create file"
UserInfo=0xa79750
{NSUnderlyingError=0xa79860 "The
operation couldn’t be completed.
(OSStatus error -12115.)",
NSLocalizedDescription=Cannot create
file}
Any suggestion?
I don't about the error, but i'll just list everything i did, successfully.
chmod the run script to 755 (obvious)
chmod the app binary to 4755 and chown to 0:0 (root)
Setup the Info.plist to launch the run script, not app binary (again, obvious)
Try changing your script to just: (log file not strictly necessary)
dir=$(dirname "$0")
exec "${dir}"/AppBinary
That's everything i did, and it works perfectly.
Of course, we're talking Jailbroken here, Apple would never allow this in the AppStore.
I am currently learning LINUX commands and I am wondering how to run commands within the .plan file.
For example i want to a message as would be output from the ~stepp/cosway programs.
I typed ~stepp/cosway "HELLO" but it didn't work. What is the command for that?
Also how do I set all files in the current directory and all its subdirectories recursively to have a group of admin?
The .plan file is a plain text file that is served by the fingerd daemon. For security reasons, it's not possible to execute commands from that file, unless you modify and recompile fingerd on your machine to do so.
Concerning the second part of your question, use chgrp:
$ chgrp -R admin *