I have managed to extract all attachments from emails being delivered to a certain email to a public folder on my linux server (using postfix->procmail->uudeview). Unfortunately the files themselves are saved with the permissions restricted to the system user that the files were sent to (called 'scans').
How can I build a "chmod 777 /path/to/folder/*.pdf" into my setup so that the files (which are coming from my scanner) are available to anyone?
Is there a better way to do this?
Regards
Frank
Whatever it is that you are doing, chmod 777 is so misdirected as to lose your computer driver's license. It is a serious security problem to make files world-writable and executable.
You are probably looking for Procmail's UMASK variable. If permissions are too tight, set a more relaxed UMASK before delivering. Example:
:0
* some conditions
{
UMASK=003
:0
| uudeview --whatever
}
The umask system call can only strip permissions, not add them. Typically, a C program tries to create a data file using mode 0666 and then the umask is applied, often yielding something like 0644 (meaning the effective umask was something like 0022 or 0033). On Linux, the directory's permissions also somewhat influence the permissions of newly created files. But we are venturing outside of Procmail here. Perhaps you can achieve the end result you require by combining the UMASK facility of Procmail with directory permissions.
If the "attachments" you are extracting are not MIME attachments but actual uuencode, note also that the encoding specifies permissions for every encoded file. If the begin line says 644 then you might have to change that. Procmail to the rescue again!
:0
* some conditions
{
UMASK=003
| sed 's/^begin [0-7][0-7][0-7][0-7]* /begin 664 /' | uudeview --whatever
}
In the end, if even this doesn't help, it may come down to modifying uudeview, perhaps by tweaking its source, or by creating a wrapper which fixes up permissions after writing.
Related
Is it safe/necessary to do the following:
RUN chmod 777 /cassandra-start.sh
ENTRYPOINT ["/cassandra-start.sh"]
Thanks
It is not safe.
If the shell executing this script is bash, it can and will (in some circumstances) read updates to the script it is already interpreting, so even if changes are scoped by Docker's copy-on-write nature to a single instance, the behavior of that instance can be modified by code which has minimal (even nobody) permissions within it.
In most Docker filesystem backends, guest filesystems are accessible on the host. Leaving executable files world-writable on the host means that any user with +x permissions to its parent directories can modify that content.
It is not necessary.
Execution of a script requires +r and +x. It does not in any respect require +w. Thus, 755 is generally sufficient.
If you have runtime configuration which takes place based on programatically modifying a script, the way to do this without permitting shell injection attacks is instead to modify a data file that script reads (and to ensure that the manner in which this data file is interpreted does not contain any eval-equivalent practices). That is to say, if you currently have code modifying a variable in your script with sed -e 's/variable=.*/variable=foo/', have your script contain variable=$(<var.file), and modify the contents of var.file.
I`ve created simple script which is based on inotify-tools, but finally after when i decided to monitor /remotepath, which was mounted from NAS by command mount.cifs, it wasnt work.
So after some investigation i found information, that inotify-tools has not support for remote folder.
Does any one of You have any expirience with simple tool which will give me a chance, to watch remote folder, and if something will change, then will run rsync.
Maybe i should go only with rsync and sync remote folder with new files only ?
Thanks for any ideas.
In the mean time i created some simple bash script which doing this what i want, but i fighting with a problem, what will happend if something will be deleted from destination folder and i dont want to synchronize this deleted file again.
Any idea how to fix this problem ?
#!/bin/bash
### Logs path
path="/var/log/compare"
log="compare.log"
listing1="listing1.log"
listing2="listing2.log"
### Path which will be monitored
destination="/path/to/destination/"
source="/path/to/remote/folder"
## Watching for content in source folder
ls -lh $source > $path/$listing1
### I`m checking if something was changed
echo "$(date)" 'INFO' 'I will compare listing files' >> "$path/$log"
if cmp -s "$path/$listing1" "$path/$listing2"
### Files are the same
then
echo "$(date)" 'INFO' 'Listings are the same' >> "$path/$log"
### Files are different
else
rsync -art $source $destination
echo "$(date)" 'INFO' 'Finished synchronization' >> "$path/$log"
fi
cp $path/$listing1 $path/$listing2
inotify is indeed the wrong tool for the job; it works by intercepting filesystem activity in the kernel, so remote activity will be totally missed.
An ideal solution would be to run inotify on the NAS box. This is certainly possible with some devices, but you don't say what device you have (and if you did I probably don't have the same one).
Any other tool that exists will just do exactly what your script does (albeit maybe more prettily), so I don't think you need to pursue that avenue.
In any case, your script is entirely redundant! If you just ran rsync periodically it would do exactly the same thing (rsync -t just compares the file names, sizes, and timestamps). The only difference is that rsync will compare the remote file list against your real files, not a cached copy of the file-list. Incidentally, -a implies both -r and -t, so rsync -a is sufficient.
One thing I would look into: running rsync on the NAS device directly. Accessing the file list through CIFS is less efficient that running it locally, so if your NAS can support rsync then do it that way. (Synology NAS boxes have rsync, but I don't know about other devices.)
I wanted to know how can I set right permission for my file /log/production.log? Everyone is saying just use chmod or chown but no one explains what I should wright after these commands. I am beginner and would appreciate if you could explain.
In my particular example I have rails app on production server where I need to set permission to production.log file in /var/www/my_app/log/ directory.
Here is what documentation is asking from me:
By default, Phusion Passenger runs Rails applications as the owner of
config.ru. So the log file can only be written to if that user has
write permission to the log file. Please chmod or chown your log file
accordingly.
Hope you can help. Thanks.
Try chmod 0660 production.log and take a look at this explanation/diagram of chmod.
chmod allows change the permissions of a file or a directory. Exists three basic permissions (read,write,execute) for three differents groups (owner,group,other).
chown allows change who is the owner of a file or a directory.
I recommend you use chmod 640. Looking the syntax of chmod here you're defining the production.log's owner (usually root) can read and write this file. If you want, you can give read-access for all users of the same group of the owner. But you shouldn't offer permissions for other people, even less in a production environment.
I would create a deploy user for your application, say myapp (doesn't particularly matter what the name is). The use this user to deploy/manage your application. Assuming username myapp
chown -R myapp:myapp /var/www/my_app
and then restart nginx/passenger. This will cause passenger to run as the myapp user, and allow it to write logs under the logs directory. (Also make sure that you don't have /var/www as the docroot, accessible outside of passenger as it can cause information leakage)
another option, if the server isn't shared, is that you can run as the www user. so
chown -R www:www /var/www/my_app
which should allow the process to write to your logs.
My lab sheet says that if the $PATH in root has a trailing ".", it is likely that an attacker can gain superuser access by forcing an admin to operate as root to execute some malicious program. I dont understand this at all! Can someone explain to me what the above sentence means? And how do I remove the "."?
echo $PATH
/usr/sbin:/usr/bin:/usr/openwin/bin:/usr/ucb:.
This is in Solaris 10 btw.
In your ~/.profile file or maybe in your ~/.bashrc file (By ~/ I mean your home directory)
export PATH=/usr/sbin:/usr/bin:/usr/openwin/bin:/usr/ucb
Now you have removed the trailing .
BTW: /usr/xpg4/bin has more modern versions of commands like awk - you may want to put it in your PATH variable before /usr/bin unless you were instructed to keep your PATH as is.
What the statement refers to is this:
Suppose the bad guys corrupted some executable file. One that lives in an application directory.
If you cd to that directory and then typed the name of the bad file it would run. And you might not know it happend. Maybe the file sends masses of of email all over the world. Or places a worm in some other executable file in your home directory. You get the idea.
Running Ubuntu 10.04 on Linode, RVM, Rails 3, Apache with Passenger module, carrierwave and mini-magick
I get:
Rails Error: Unable to access log file. Please ensure that /srv/www/mysite.com/testapp/log/production.log exists and is chmod 0666. The log level has been raised to WARN and the output directed to STDERR until the problem is fixed.
and Errno::EACCES (Permission denied /srv/www/mysite.com/testapp/public/uploads/tmp/20110517-1707-2938-6455):
I ran chmod -R root:root /srv/www/mysite.com/testapp
Then: chmod -R www-data:www-data /srv/www/mysite.com/testapp & chmod -R www-data:www-data /srv/www/mysite.com/testapp/public/uploads
Since the only 2 directories that should be writable is the log files and uploads directory I tried to secure the rest. Are there any other folders / files that I need to make writable?
Permissions on web sites is a little strange: on the one hand, the content needs to be readable by the webserver and FastCGI or Passenger or whatever executes the (in this case, Ruby) code. On the other hand, if the webserver user owns the files, then a hacked webserver or (more likely :) your code could modify the executable files and static files that are your website. It happens too often.
If the content of the website is owned by some other user, not writable by the web server software, then the website can not be overwritten by attackers. (Of course, you have a few open sockets to a database connection; all the database backed data can be corrupted by attackers. Also, any directory where you allow uploads could be corrupted by attackers. But the goal is to reduce the privileges of the software as far as reasonable.)
So, all that said, on to your specific question; your webserver software runs as www-data, and it makes sense for your log files and upload directory to be owned by www-data:
mkdir -p /srv/www/mysite.com/testapp/log/ # might not exist yet
chown -R pcasa:pcasa /srv/www/mysite.com/ # or some other user
chmod 755 /srv/www/mysite.com
chmod 755 /srv/www/mysite.com/testapp/
# populate the app directory with your files, if you haven't done so already
chown -R www-data:www-data /srv/www/mysite.com/testapp/log
chmod 755 /srv/www/mysite.com/testapp/log # see notes
chmod 644 /srv/www/mysite.com/testapp/log/* # see notes
I made the assumption that all users on your system can read the log. This might not be true. Use 700 in place of 755 and 600 in place of 644 if you don't want all system users to read the log files.
Next, for your uploads directory:
mkdir -p /srv/www/mysite.com/testapp/public/uploads/tmp # might not exist yet
chown -R www-data:www-data /srv/www/mysite.com/testapp/public/uploads
chmod 755 /srv/www/mysite.com/testapp/public/uploads
chmod 755 /srv/www/mysite.com/testapp/public/uploads/tmp
Again, I've made the assumption that all users on your system can be able to see all the uploaded content. Use 700 in place of 755 if you just want the webserver software to be able to read the files.
These are simple guidelines that should work; you can get more complicated if you want to keep the website software and content shared only between the user that owns the website and the user that runs the website, by running the webserver with a supplementary group (see newgrp(1) and group(5) manpages for details) and giving the files the same group owner, and using the group permission bits (the middle octal number: 750 vs 700). It's complicated enough that unless you've got a good reason, it's probably not worth going down this route. (Definitely worth doing once on a development machine somewhere, just so you're familiar enough with it that you can use it in the future. :)