I'm trying to create files and directories and executing a script with a specific user instead of root user. How can I do that? I don't want to switch users from root user to another user; instead, I always want it to use a specific user, for example, wasadmin user.
Whenever I'm creating a new file or executing a script, this should be run as wasadmin user. Can you please help me with this?
It depends on how you create the file. As far as I know, it's not possible to do this when you use touch or echo, but depending on the way you create the file, there might be a possibility to add a user parameter.
In case this is not possible, you might use the chown command (change ownership), this command gives the possibility to modify the owner/group of an already created file (which obviously means that you can only do this after the file has already been created). I've been looking for an official chown reference, but I think that launching the command man chown can answer all questions you might have on this command.
Related
I'm trying to run crontab as a user, but any of the scripts won't execute. How I can fix this? Consider that:
I tried with BOTH crontab -e and sudo crontab -u username -e;
Scripts are correctly written, since they are executed if I run them
with root crontab;
In cron.allow there are both root and user.
Crontab Permissions:
There are two files that control the permissions for crontab: /etc/cron.allow and /etc/cron.deny.
If there is a cron.allow file, then the user or users that need to use cron will need to be listed in the file. You can use cron.deny to explicitly disallow certain users from using cron.
If neither files exist, then only the super user is allowed to run cron. Well, that depends on the system specific configuration to be exact. Most configuration do not allow any users to run jobs, while some systems allow all users to run jobs by default.
So, the first step is to create a file named cron.allow in the /etc/ folder. Add the user name to this file in order to allow the user to run jobs.
Once the proper permissions has been set, the user should be able to modify and run jobs using the crontab command.
I have few data sets whose write access needs to be transferred to another user.I am aware about chmod command, but if i am using that then i am giving write permission to all other users. I just want file owner write access be transferred or be given to another single user.
Instead of CHMOD, use CHOWN:
chown command changes the user and/or group ownership of for given file. The syntax is:
chown owner-user file
chown owner-user:owner-group file
chown owner-user:owner-group directory
chown options owner-user:owner-group file
Source: http://www.cyberciti.biz/faq/how-to-use-chmod-and-chown-command/
chmod allows you to grant file permissions to specific users via the use of Access Control Lists (ACLs). Without knowing more about your system it's difficult to advise on how to create one of these - e.g. Solaris is quite different from Linux in this regard.
Noticed this when creating a new directory in unix, and was just curious as to why this is so.
Thanks
A new directory created by a user and owned by the user with full permissions is no big deal. However, a new file/program if executed accidentally or before configuration could have catastrophic results. So the designers decided to give you a layer of protection.
It also prevents other users from executing the file unless you specifically grant permission.
Because you need the executable permissions to naviguate into the directory.
So basic permissions allow user to read file (read file permission), and to access file in directory (directory execute permission).
Note that read permission on a folder allow user to list files in it. (But doesnt allow to read them unless execute permission is granted too as I said in the first place)
Basically, +x on a directory means that the user can 'execute it' hence change into it (replace user by group or other depending on position in permissions).
Hence drwxr--r-- means only user can change into directory. More here.
The directory needs to have executable permissions so you can do things such as cd into it. Also the executable permission lets you look into the directory for inode information of the files it contains.
More info can be found at this source.
I get this problem now and then, where I use an FTP account given to me by the host and use them in Wordpress FTP. But for some reason when updating themes for example, the new theme gets created under apache/apache and not user/psacln user name/group. So at that point I can't delete or do anything with those files as I am under psacln group.
I would like to find out more about why this may happen to avoid this problem - any suggestions are welcome!
Thanks in advance.
When you upload files via the wordpess admin page (like themes) the httpd process running as the apache user is actually creating them on your system--hence why they are owned by the apache user. I suggest this options to work around this:
Add yourself and apache to a new group called 'wordpress'
Use to change group ownership of your wordpress to the new group
Use set the sgid permission bit and the group write permission to all directories in the wordpress docroot.
The setting of the sgid bit will make all files added to a directory be the same group owner.
Assuming you've added yourself and apache to the same group, here's the linux commands to setup the directories to ensure files get created writable to all in the wordpress group:
chown -R :wordpress /path/to/wordpress/docroot/
chmod -R g+w /path/to/wordpress/docroot/
find /path/to/wordpress/docroot/ -type d -print | while read i; do SAVEIFS=$IFS; IFS=$(echo -en "\n\b");chmod g+s $i; IFS=$SAVEIFS; done
Additional thing that may be needed:
If you see apache creating files with group permissions without write, you may need to change the default umask for the apache user for creation of new files. By default it should be owner and group write allowed, but I know some accounts (like root user) have the default umask set to be group read only.
because apache's worker children run under apache's userid, and a "common user" on a unix system cannot make files be owned by some OTHER user. Only the root account can "give away" ownership.
Why? It'd be trivial for a normal user to make a file owned by root, or owned by another user. If a given system was running with user quotas, this would allow a user to completely subvert the quotas, or deny someone else access by "giving" them a bunch of huge files and exceeding that user's quota.
If you need access to those files, regardless of the unix ownership, you could look into using POSIX acls, which exist above/beyond the unix permissions.
Is there a way to flush all of the image directories at once? Perhaps using Drush?
Also, from the command line, with drush installed:
drush image-flush
which gives you a drop-down of all catagories. Choose 'all'!
I've done this on my system, but make sure you back it up when you test it out yourself.
Simply delete the styles directory in your files directory. They will re-create as they are loaded.
i.e. from the command line, from your web root, you would run:
$ rm -rf sites/default/files/styles
You may run into permission issues as those files will be owned by the web user. In that case, maybe you could have a form & submit handler in a module delete those files since that would be run by the web user. That is another topic though.