I am deploying a war file in JBoss on a linux server.
The application is in its own standalone dir and not the default.
e.g. jboss/standalone-application rather than jboss/standalone.
I use sudo su - myappuser to switch to the application user and run the start script.
When running the application the jboss/standalone/log/ directory doesn't yet exist.
When I kill the process with pkill -9 -f myapp a jboss/standalone/log/server.log file appears and is owned by root yet all the other files and directories in the installation dir are owned by the application user (as expected).
How is it possible that this file is being created with root permissions when the process is started and stopped by a user?
Related
I have a need to make any files that are created in the specific Linux directory to have 777 permission.
I would like to have all the users to be able to do Read, Write and Execute on all files under this folder. So what is the best way or Linux command to make it happen?
What I am doing is that I am spinning off two separate containers one for Nginx server and one for PHP:FPM app server to host Laravel 5.4 app.
Please consider the following scenario. I have a docker application container A (PHP:FPM) which is used to serve the web application files to docker container B (Nginx). Now when I access the website, I am delivering the web pages through the web container. Both the containers are within the same network and I share the volumes from my app container to my web container. But when the web container tries to read the files on the app container I get the error which is something like below:
The stream or file "/var/www/storage/logs/laravel.log" could not be
opened: failed to open stream: Permission denied
So I added RUN chmod -R 777 storage in my docker file.
However it is not solving the issue.
So I also tried using SGID to fix the issue by adding one more line in my dockerfile as RUN chmod -R ug+rwxs storage. Still it is not solving the issue of permission.
On a separate note, funny thing is that on my MAC Docker container this works without any issue ( I mean without adding chmod -R 777 to folder or using SGID for setting permission to a folder in my docker file). But when the same code is run on Linux AMI EC2 instance (Amazon AMI Linux EC2) ... the permission issue start to occur.
So how do I fix this ?
The solution is to launch both containers using the same user identified by the same uid. For instance you can choose root or any uid when running the container:
docker run --user root ...
Alternatively, you can switch to another user, before startup, inside your Dockerfile by adding the following before the CMD or ENTRYPOINT
USER root
I have solved it by figuring out user name under which cache files are created when someone access the application url . And then updating my dockerfile to include statement for SGID ownership for that user on the root of app folder where all source code resides (so all subfolder and files included later in whatever way ... at run-time sometime... are accessible from web container for that user) and then using chmod 777 permission on specific folders that needs to have chmod 777 permission.
I tried to start jobs service with non root user and group but I received runuser cannot set groups operation not permitted jobs error in /var/log/jboss-as/console.log. I installed and configured jboss service with non root user. It worked fine with root, but failed to start/stop/restart jboss service with non root user. I have no ideas why this happened.
give permissions to the folder like
chmod 775 -R
I have a AWS ec2 instance with Amazon Linux AMI running. As the web server I installed Apache and the web directory is /var/www/html.
Until now I had the permission for /var/www/html set as 777 under the user c2-user (chmod -R 777 /var/www/html).
I read, that you should usually have set the 644 permission for web access. But as soon as I do that, I get the 403 forbidden error message. What do I have to change?
The difference between '7' and '6' is the execute bit. That's important on directories because it allows other users to enter the directory. Since the dir is opened by ec2-user and Apache runs as another user, the third number (of 777) comes into play.
On individual files it may be okay to use permissions of 644, as that prevents other users from being able to modify the file. This isn't always true, though- executable files need the executable bit and logs need to be writeable by their process.
Here's a quick overview on directories and unix permissions: https://unix.stackexchange.com/questions/21251/why-do-directories-need-the-executable-x-permission-to-be-opene
Do I need to have root access for deploying my application on Linux through Chef-solo. Though the Chef solo was installed previously by user with root privileges.
Chef client is typical linux app. If someone install it for you and add +x privileges for your user on chef-client file and you can read and write to chef temp folder - you can use it.
If you want use chef-client with root privileges, but don't want use root user - you can set setuid and setguid bit on chef-client file.
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.