Magento log file permission issues - magento

I have a standard Magento application where actions are performed either through web (www-data) or cron scripts (executed by a cron user). By default, Magento creates log files with chmod 0640 so this gives us a problem. Whoever logs an exception/system first (www-data or cron), the other won't be able to append. So if an exception occurs on the web, the var/log/exception.log will be created with www-data as owner so cron scripts won't be able to log exceptions in the same file (cron and www-data are not in the same group but even if they would be, it wouldn't help).
Possible solutions:
1. Run cron with same www-data user (sysadmin won't budge, doesn't agree with the solution)
2. Change Mage.php to generate the log files with a more suitable chmod (even 777 maybe). Doable but this means modifying Magento core files (Mage.php) and it's not really allowed by license.
Mage class is final and I noticed there is no pre- or post- events after logging in order to possible change the chmod in a pre/post hook.
Has anybody encountered the same problem or has any advice on how to properly handle this?

Your proposed first solution sounds as the valid one to me. The cronjob should run with the www-data user. Only then you can guarantee that the file permissions match, regardless if web server or cron job.
Otherwise how can you guarantee that running the cronjob as different user a the web server will give you the same result?
Modifying Mage.php is not a right solution as you already stated. Never modify core files directly as you are going to run into problems when updating Magento - e. g. overwriting files.

From my point of view the web user should not be same user like the shell/cronjob user. They can use the same group, but different users are more secure.
In our case web/http-user is:
httpd:site
and shell/cron user is:
prod:site
So users are different, but belong to the same group. For our case log permission 640 is too restrictive.
Its done in Mage.php
chmod($logFile, 0640);
We change them by script from 0640 to 0660 by s simple script
$command = 'find '.realpath(dirname(__FILE__)).'/var/log/ -type f -exec chmod 0660 {} +';
exec ($command);
which is executed by cron shell and wget

Related

making a file only writable and visible from a script

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.

Is it possible to pipe the password to login as root , rather that typing the password when it prompts in command line?? - Korn shell

I have a custom requirement by a specific user , that he wants me to write a shell script to move files from one folder to another folder . These two folders have different owners
Now, I managed to do that by logging in as root, but want to achieve this without giving root privileges to user.
I am not allowed to do any new package installation,
Not allowed to use any another shell than Korn .
Please suggest a solution.
Yeah I know this is not a safer way and a bad approach, still am curious about satisfying the need of a user ..
Write a script to move files.
change the ownership of the script to root
Update the /etc/sudoers file to give the user permissions to run the script as root:
user ALL = NOPASSWD: /opt/script.sh
User can execute the script: sudo /opt/script.sh
That shouldn't ask for root password, but give the user privileges to run the script as root.

Change Owner of a script in unix

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

Execute permissions on downloaded file

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.

How to change Unix permissions when I don't own the file but do have write permission on the directory?

I'm sharing a git repository with a colleague, and because git does not propagate the full panoply of Unix file permissions, we have a "hook" that runs on update which sets the 'other' permissions as they need to be set. The problem? The hook uses chmod, and it turns out that when my colleague commits a file, he owns it, so I can't run chmod on it, and vice versa. The directories are all group writable, sticky, so I believe that either of us has the right to remove any file and replace it with one of the same name, same contents, but different ownership. Presumably then we could chmod it. But this seems like an awfully big hammer, and I'm a bit leery of screwing it up. So, two questions:
Can anybody think of another way to do it?
If not, what's the best design for a bulletproof shell script that implements "make this file belong to me"? No cross-filesystem moves, etc etc...
For those who may not have realized, write permission does not confer permission to chmod:
% ls -l value.c
-rw-rw---- 1 agallant ta105 133 Feb 10 13:37 value.c
% [ -w value.c ] && echo writeable
writeable
% chmod o+r value.c
chmod: changing permissions of `value.c': Operation not permitted
We are both in the ta105 group.
Notes:
We're using git not only to coordinate changes but to publish the repo as a course web site. Publishing the web site is the primary purpose of the repo. The permissions script runs at every update using a git hook, and it ensures that students do not have permission to read solutions that have not yet been unveiled.
Please do not suggest that I have the wrong umask. Not all files in the repo should have the same permissions, and whatever umask is chosen, permissions on some files will need to be changed. Not to mention that it would be discourteous for me to impose my umask preferences on my colleagues.
UPDATE: I've just learned that in our environment, root is quashed to nobody on all machines we have access to, so that a solution which relies on root privileges won't work.
There is at least one Unix in which I've seen a way to give someone chmod and chown permissions on all files owned by a particular group. This is sometimes called "group superuser" or something similar.
The only Unix I'm positive I've seen this on was the version of Unix that the Encore Multimax ran.
I've searched a bit, and while I remember a few vague references to an ability of this sort in Linux, I have been unable to find them. So this may not be an option. Luckily, it can be simulated, albeit the simulation is a bit dangerous.
The way to simulate this is to make a very specific suid program that will do the chmod as root after checking that you are a member of the same group as owns the file, and your username is listed as having that permission in a special /etc/chmod_group file that must be owned by root and readable and writeable only by root.
The most straightforward way to do this is to make your partner and you members of a new group (let's say "devel"), and have that as the group of the file. That way it can be owned by either of you, and as long as the group is right, you can both work with it.
If that doesn't work with you, "sudo" can be configured such that only those two users can run a chmod command on files in that specific directory as root with no password.
If you set your umask correctly, the files could be created with the correct permissions in the first place:
$ umask 0022
$ touch foo
$ ls -l foo
-rw-r--r-- 1 sarnold sarnold 0 2011-02-20 21:17 foo
$ rm foo
$ umask 0002
$ touch foo
$ ls -l foo
-rw-rw-r-- 1 sarnold sarnold 0 2011-02-20 21:17 foo
I'm taking a step back. Let me know if I'm violating some restriction in your system I haven't read.
From your question, I assume you're trying to share a git repository using file:// URLs and relying on the UNIX filesystem permissions to take care of authorisation etc. Why don't you consider another way to share your repositories that doesn't involve this hassle?
I can think of two ways.
You can create bare repository on either of your machines, add that as a remote to your working repos and use it to collaborate. Serving it can be done using the inbuilt git daemon command. Detais are here. This will however not give you any access control.
You can install gitosis locally and use that to serve your repository. This allows a simple access control system so that you can restrict/allow certain users.
There was a related question that came up a while ago that might be relevant. git daemon worked for him - Administrating a git repo without root permissions
I also found something on server fault that might be relevant to your problem - https://serverfault.com/questions/21126/git-daemon-and-access-control-for-multiple-repos
Probably not the most elegant way, but it seems to work
$ umask 0002
$ mv value.c value.c.tmp
$ cat value.c.tmp > value.c
$ rm value.c.tmp
one could argue that it could be made bulletproof, but then someone brings along a RPG...
If both of you need to chmod, I can not think of another way - if it is OK that YOU can chmod but no the other guy, you can chmod 6770 . or chmod g+s,u+s . in the directory (e.g. set SUID and GUID bits) so the one that owns the directory will always be the owner of the files. Unfortunately some (if not most), namely EXT2/3/4 ignore the SUID bit.
Of course, setting the umask to 0002 will solve the problem by not making it mandatory.
Assuming that your publishing hook actually deploy files, rather than just setting permissions in the working copy, you could deploy to a temporary location then use rsync to ensure that the file contents and permissions are correct.
Slightly nicer, but requiring some infrastructure which I'm guessing isn't in place, would be to ensure that the deploy script only runs under one user. You could do this using sudo, if your sysadmins allow, or by setting up a git server service, like gerrit, or even by having a cron job run every five minutes which checks for updates and deploys if necessary.
This might work:
touch $name.tmp
chmod 660 $name.tmp
cp $name $name.tmp
if cmp $name $name.tmp 2>/dev/null; then
rm $name && \
cp $name.tmp $name && \
rm $name.tmp
fi
It's just a variation of your original idea
Ok, a mixture of things that build on previous answers:
you can set the umask of a folder if you mount it at fstab. If you could agree with people to work on that mount, you could enforce g+w
If you set the group-id bit of that folder (g+s) all files will belong to the group the folder belongs to, so the group ownership of the file propagates
Is that doable? Of course enforcing that mount point is no easy task. Any better ideas around that one anyone?

Resources