I'm trying to get my php cgi processes to read from a file on my filesystem. Both the file and parent folder have all rwx permissions allowed and the file has the same owner and group id as the php processes, www-data.
No matter how I try to open the file (read(), file_get_contents(), stream_get_contents()) I always get the same error:
failed to open stream: Permission denied
I have no problem opening the file in the php interactive session, using cat on the command line, or with python.
What is going on?
I've seen this problem before on Linux systems with SELinux enabled. The httpd process is typically given its own security context that only allows certain files to be accessed.
You can check to see if SELinux is enabled by running ls --scontext on the file and on the php script. If the two files have the same context or if ls complains about the argument then SELinux is probably not the cause of the problem.
Assuming SELinux is the cause of problem then you could try setting the file in question to have the same security context as your php script with the chcon command. For example:
chcon --reference=/var/www/html/page.php /data/filetoread
where /var/www/html/page.php is your php script and /data/filetoread is the file that you want to access.
It turns out this file was under a FUSE filesystem which had not been mounted with the allow_other option.
Related
I have on my Ubuntu 16.04 VM in /etc/sudoers.d/waagent the configuration that is unwanted. Even if I log as root, root has only read permission.
How should I safely edit configuration for Azure waagent?
I wanna change
someuser ALL=(ALL) NOPASSWD:ALL
to
someuser ALL=(ALL) ALL
Can I simply add write permission for root and edit the file or need I do it in different way via Azure commands?
I would like to prevent the case when sudo configuration is damaged due fact I have no physical access to VM and cannot fix it.
For your issue, I think there is no more safe way to edit the /etc/sudoers.d/waagent(in my side, the file name is /etc/sudoers.d/90-cloud-init-users). The file just can be edited with the root permission. If you use the root to edit then everything works in the same way.
So I suggest you can just use the root user, add the write permission and edit the file as you want. But do not forget to change the permission back, in other words, remove the write permission when everything is OK.
Short answer:
Use visudo -f /etc/sudoers.d/waagent
Long answer:
When editing sudoers files, always use visudo. It is a vi editor, but includes built-in checks to prevent you from corrupting the file and will allow you to save the file even though there's no write permissions on the file (assuming you run it as root). Changing the permissions on the file to allow write access and using a normal text editor is a bad idea. Too easy to forget to change it back and one misplaced symbol or misspelled word can corrupt the file. That's why there is no write permission by default - to act as a check to prevent unwanted modifications that could potentially render your system unusable.
i have written a bash script. If I run this script manually on same server then its output is
CRITICAL:Something really bad is happening on server.CPU load of Process id: 11109
for user: root with command: java is 76.5
Then I configured its alert on nagios, and nagios is reading its output like
CRITICAL:Something really bad is happening on server.CPU load of Process id:
for user: with command: is
Means values are missing driven from file.
That's most likely happening because generally Nagios uses a user "nagios" or "nrpe" to execute the script plugins and that user is not able to view all processes like root does or does not have the permission to read the file you are asking it to read. You should give the nrpe user permission to read via "sudo" to solve your issue. Please note that in order to run sudo with a user that does not log in(as the Nagios user), you also nees to commebt out the Require tty parameter from /etc/sudoers file.
Im trying to use a script ,thats started by apache through the server, to change the ifcfg-eth0 file in network-scripts.
I have SELinux disabled so thats not the issue. Also I changed the whole /etc/ group and user to apache, yet it still did not work.
The script does work if I put the file in /var/www/cgi-bin.
I also get a permission denied error in the apache log file.
I can't bring myself to help you make Apache write to files in /etc/sysconfig/network-scripts/. But there is another option: create a symlink from /etc/sysconfig/network-scripts/ifcfg-eth0 to a file that Apache can write to, for example:
mv /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-eth0.bak
ln -s /var/www/cgi-bin/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-eth0
This way, your (ahem, dangerous) CGI script can rewrite the file in /var/www/cgi-bin, and the system can get the network settings from it.
I'm asking in both contexts: technically and stylistically.
Can my application/daemon keep a pidfile in /opt/my_app/run/?
Is it very bad to do so?
My need is this: my daemon runs under a specific user, and the implementor must mkdir a new directory in /var/run, chown, and chgrp it to make my daemon run. Seems easier to just keep the pidfile local (to the daemon).
I wouldn't put a pidfile under an application installation directory such as /opt/my_app/whatever. This directory could be mounted read-only, could be shared between machines, could be watched by a daemon that treats any change there as a possible break-in attempt…
The normal location for pidfiles is /var/run. Most unices will clean this directory on boot; under Ubuntu this is achieved by /var/run an in-memory filesystem (tmpfs).
If you start your daemon from a script that's running as root, have it create a subdirectory /var/run/gmooredaemon and chown it to the daemon-running user before suing to the user and starting the daemon.
On many modern Linux systems, if you start the daemon from a script or launcher that isn't running as root, you can put the pidfile in /run/user/$UID, which is a per-user equivalent of the traditional /var/run. Note that the root part of the launcher, or a boot script running as root, needs to create the directory (for a human user, the directory is created when the user logs in).
Otherwise, pick a location under /tmp or /var/tmp, but this introduces additional complexity because the pidfile's name can't be uniquely determined if it's in a world-writable directory.
In any case, make it easy (command-line option, plus perhaps a compile-time option) for the distributor or administrator to change the pidfile location.
The location of the pid file should be configurable. /var/run is standard for pid files, the same as /var/log is standard for logs. But your daemon should allow you to overwrite this setting in some config file.
/opt is used to install 'self-contained' applications, so nothing wrong here. Using /opt/my_app/etc/ for config files, /opt/my_app/log/ for logs and so on - common practice for this kind of application.
This away you can distribute your applications as a TGZ file instead of maintaining a package for every package manager (at least DEB since you tagged ubuntu). I would recommend this for in-house applications or situations where you have great control over the environment. The reasoning is that it makes no sense if the safe costs more than what you are putting inside (the work required to pack the application should not eclipse the effort required to write the application).
Another convention, if you're not running the script as root, is to put the pidfile in ~/.my_app/my_app.pid. It's simpler this way while still being secure as the home directory is not world-writeable.
I'm writing a new daemon, which will be hosted on Debian Linux.
I've found that /var/log has root only write permissions, so my daemon cannot write log files there.
However, if it writes there, it appears it will gain automatic log rotation, and also work as a user might expect.
What is the recommended way for a daemon to write log entries that appear in /var/log, without having to be run as root?
The daemon is a webserver, so the log traffic will be similar to Apache.
You should create a subdirectory like /var/log/mydaemon having the daemon's user ownership
As root, create a logfile there and change the files owner to the webserver user:
# touch /var/log/myserver.log
# chown wwwuser /var/log/myserver.log
Then the server can write to the files if run as user wwwuser. It will not gain automatic log rotation, though. You have to add the logfile to /etc/logrotate.conf or /etc/logrotate.d/... and make your server reopen the logfile when logrotate signals it should.
You might also use syslog for logging, if that fit's your scenario better.
Two options:
Start as root, open the file, then drop permissions with setuid. (I don't remember the exact system calls for dropping permissions.) You'll have to do this anyway if you want to bind to TCP port 80 or any port below 1024.
Create a subdirectory like /var/log/mydaemon having the daemon's user ownership, as WiseTechi said.
Files under /var/log aren't automatically rotated; instead, rotation is controlled by /etc/logrotate.conf and files under /etc/logrotate.d.
use the "logger" command
http://linux.die.net/man/1/logger