I'm trying to get user directories to work with Lighttpd on Arch Linux. But after creating the public_html directory, placing an index.html file in it, setting permissions, configuring Lighttpd to use the user directory module, and restarting lighttpd, it still gives 404 for one specific user (yet another one works).
Here are my configuration files:
$ cat /etc/lighttpd/lighttpd.conf
# This is a minimal example config
# See /usr/share/doc/lighttpd
# and http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs:ConfigurationOptions
server.port = 80
server.username = "http"
server.groupname = "http"
server.document-root = "/srv/http"
server.errorlog = "/var/log/lighttpd/error.log"
dir-listing.activate = "enable"
index-file.names = ( "index.html" )
mimetype.assign = (
".html" => "text/html",
".txt" => "text/plain",
".css" => "text/css",
".js" => "application/x-javascript",
".jpg" => "image/jpeg",
".jpeg" => "image/jpeg",
".gif" => "image/gif",
".png" => "image/png",
"" => "application/octet-stream"
)
include "conf.d/userdir.conf"
include "conf.d/cgi.conf"
$ cat /etc/lighttpd/conf.d/userdir.conf
server.modules += ( "mod_userdir" )
userdir.path = "public_html"
This is what things look like for user aardbei:
$ cat /home/aardbei/public_html/index.html
doot doot
$ ls -ld /home/aardbei/public_html
drwxrwxrwx 2 aardbei aardbei 4096 Mar 27 13:10 /home/aardbei/public_html
$ ls -ld /home/aardbei/public_html/index.html
-rwxrwxrwx 1 aardbei aardbei 37 Mar 27 13:11 /home/aardbei/public_html/index.html
But even after restarting the server with sudo systemctl restart lighttpd I still get 404 at URI /~aardbei/index.html and not what I should get: "doot doot"
However, this is what things look like for the user madeline:
$ cat /home/madeline/public_html/index.html
blah blah blah
$ ls -ld /home/madeline/public_html/
drwxrwxrwx 19 madeline madeline 4096 Mar 27 13:33 /home/madeline/public_html/
$ ls -ld /home/madeline/public_html/index.html
-rw-r--r-- 1 madeline madeline 15 Mar 27 13:33 /home/madeline/public_html/index.html
So the important parts are the same. And yet going to URI /~madeline/index.html does what it should do: it shows "blah blah blah"
Nothing looks relevant here, but here are groups for the two users:
$ groups madeline
wheel video audio wireshark madeline
$ groups aardbei
wheel aardbei
What is going on? Why doesn't the user directory for the user aardbei work in Lighttpd?
Following the instructions on the Arch Linux wiki for Apache worked: https://wiki.archlinux.org/index.php/Apache_HTTP_Server#User_directories
$ chmod o+x /home/aardbei
$ chmod o+x /home/aardbei/public_html
$ chmod -R o+r /home/aardbei/public_html
I'm still not sure I understand the permissions at play here, but it solves my problem.
The reason that the accepted answer works is due to the user that the web server is running as requiring access to the user's home directory in order to access their public_html.
Granting o+x allows other users to access a file and/or sub-directory within but not allow them to list the contents of a directory. Basically they can pass through it so long as they know what they're looking for, public_html, but they cannot get a list of the contents otherwise.
Example
Here's my home directory:
$ ls -dl /home/sam
drwx-----x. 3 sam sam 4096 Nov 3 11:08 /home/sam
$ ls -dl /home/sam/public_html
drwxr-xr-x. 2 sam users 4096 Nov 3 11:09 /home/sam/public_html
Now as the user of the web server, lighttpd, cannot list the contents of my home directory:
$ sudo -u lighttpd ls /home/sam
ls: cannot open directory /home/sam: Permission denied
But can see a specific directory if they happen to know its name:
$ ls -dl /home/sam/public_html
drwxr-xr-x. 2 sam users 4096 Nov 3 11:09 /home/sam/public_html
Here's another directory that the web server can see too:
$ sudo -u lighttpd ls -ld /home/sam/someotherdir
drwx------. 2 sam users 4096 Nov 3 11:22 /home/sam/someotherdir
And files within the public_html are visible as well:
$ ls -dl /home/sam/public_html/index.html
-rw-r--r--. 1 sam users 3 Nov 3 11:09 /home/sam/public_html/index.html
Normal permissions apply here, so if you don't want the web server to see something, make it readonly to your user & groups but not everyone else (others).
Related
Using:
podman version 4.2.0
AlmaLinux 8.7
I've created an image based on redhat/ubi8 with the following Dockerfile:
FROM docker.io/redhat/ubi8
RUN dnf install -y gcc-c++ cmake python39 openssh git
RUN useradd -ms /bin/bash foobar -g users
USER foobar
WORKDIR /home/foobar/
RUN mkdir -p .ssh
$ docker build -t mount_test_image .
I run the image from a directory that contains a directory ssh, and I want to mount that directory to /home/foobar/.ssh with ownership of foobar.users
$ ls -l
-rw-r--r--. 1 host_user users 269 Dec 7 09:10 Dockerfile
drwxrwxr-x. 2 host_user users 18 Dec 2 10:41 ssh
docker run -it -d --rm --mount type=bind,src=ssh,target=/home/foobar/.ssh --name=mount_test mount_test_image
However when I enter the container via
docker exec -it mount_test '/bin/sh'
The home directory looks like this:
drwx------. 1 foobar users 18 Dec 7 17:10 .
drwxr-xr-x. 1 root root 21 Dec 7 17:10 ..
-rw-r--r--. 1 foobar users 18 Jun 20 11:31 .bash_logout
-rw-r--r--. 1 foobar users 141 Jun 20 11:31 .bash_profile
-rw-r--r--. 1 foobar users 376 Jun 20 11:31 .bashrc
drwxrwxr-x. 2 root root 18 Dec 2 18:41 .ssh
I obviously get a "permission denied" when trying to access that directory.
sh-4.4$ ls /home/foobar/.ssh
ls: cannot open directory '/home/foobar/.ssh': Permission denied
I tried changing the ownership of the directory on the host to match the uid of the container user, but then it just looks like this:
drwxrwxr-x. 2 nobody root 18 Dec 2 18:41 .ssh
My host user uid:gid is 501:100 and the container user is 1000:100. Right now I'm just trying to generate an ssh key to upload to bitbucket, but this seems like a simple feature a container should be have. All the tutorials and examples just stop after the --mount command instruction and say "there ya go!". What good is the mount point if you can't read/write it?
EDIT:
I tried on Archlinux using docker instead of podman and it works like one would expect with both -v and --mount. The owner of the mounted directory in the container matches the uid and gid of the host. Is this then a bug in podman or is it just done differently?
You are using a non-root user (foobar) in a rootless container. You must use --userns=keep-id for the container user to see the mounted volumes.
https://github.com/containers/podman/blob/main/docs/tutorials/rootless_tutorial.md#using-volumes
I have a proxmox server so under debian, and I want to mount a remote directory from my Nas Synologies to make backups.
I normally use ssh mounts without any problem.
But this time I have an error that I have never encountered, I can create files, but not delete them.
I find this very strange and I don't see where this can come from
root#proxmox:/mnt/# sshfs user#192.168.0.1:home/data /mnt/dist-folder/ -o reconnect,
ServerAliveInterval=60,ServerAliveCountMax=30,allow_other,
default_permissions,uid=0,gid=0,umask=007
root#proxmox:/mnt# cd dist-folder/
root#proxmox:/mnt/dist-folder# touch aa.txt
root#proxmox:/mnt/dist-folder# ls -la
total 12
drwxrwx--- 1 root root 114 Mar 13 09:53 .
drwxr-xr-x 7 root root 4096 Mar 13 09:37 ..
-rwxrwx--- 1 root root 0 Mar 13 09:53 aa.txt
root#proxmox:/mnt/dist-folder# rm aa.txt
rm: cannot remove 'aa.txt': Permission denied
With uid=0,gid=0 for root user and group
Thanks
This is finally a problem specific to synology.
For the assembly of the file it is absolutely necessary to respect the path by starting with
/homes/<user>home/
So it's give
sshfs user#192.168.0.1:/homes/proxmox/home/data /mnt/dist-folder/
And it's works fine !
It's not the first time that I have an abnormal configuration for this synology tool... AGrrrr
I'm super-confused about file permissions in MSYS. Things started to go wrong after my company transferred my windows-user to a different domain. Now I have this concrete problem:
I want to compile cpputest. I unzipped it using windows, started an msys console and owner and group look like this:
M.Grunwald#GNA ~/Projects/cpputest-3.8
$ ls -la
total 1956
drwxrwx---+ 1 M.Grunwald Domain Users 0 16. Nov 10:21 .
drwxrwx---+ 1 M.Grunwald COMPANY_DE+Domain Users 0 16. Nov 10:21 ..
-rwxrwx---+ 1 M.Grunwald Domain Users 11030 2. Mai 2016 .cproject
-rwxrwx---+ 1 M.Grunwald Domain Users 228 2. Mai 2016 .gitattributes
-rwxrwx---+ 1 M.Grunwald Domain Users 746 25. Mai 12:32 .gitignore
and so on.
When I start autogen.sh, this happens:
$ ./autogen.sh
autom4te-2.69: cannot open autom4te.cache/requests: Permission denied
$ ls -lad autom4te.cache/
drwxr-xr-x+ 1 M.Grunwald Domain Users 0 Nov 16 10:23 autom4te.cache/
So the directory belongs to me, I have all permissions, but I'm not allowed to touch anything in it:
$ touch autom4te.cache/requests
touch: cannot touch 'autom4te.cache/requests': Permission denied
It seems that "I" am not really M.Grunwald and don't belong to "Domain Users", neither... On the other hand:
$ echo "UID: $UID GID: $GROUPS"
UID: 1117609 GID: 1049089
$ ls -lnad autom4te.cache/
drwxr-xr-x+ 1 1117609 1049089 0 Nov 16 10:23 autom4te.cache/
So the IDs match. umask is 0000, too and still group and others don't have write permission. If I want to change this:
$ chmod g+w autom4te.cache
chmod: changing permissions of 'autom4te.cache': Permission denied
Now I'm completely confused and blocked on many similar tasks (always permission problems, cpputest is just one example). Can you help me?
The problem was solved after I re-ran the mingw installer.
I'm using Docker to run an Apache instance. My docker file goes something like this:
FROM ubuntu
MAINTAINER your.face#gmail.com
RUN cat /etc/passwd
RUN cat /etc/group
RUN apt-get update && apt-get install -yq apache2 php5 libapache2-mod-php5 php5-mysql
RUN apt-get install -yq openssh-server
RUN mkdir /var/run/sshd
ENV APACHE_RUN_USER www-data
ENV APACHE_RUN_GROUP www-data
ENV APACHE_LOG_DIR /var/log/apache2
EXPOSE 80
ADD config/apache2/000-default.conf /etc/apache2/sites-available/000-default.conf
ADD config/php5/php.ini /etc/php5/apache2/php.ini
ADD config/start.sh /tmp/start.sh
ADD src /var/www
RUN chown -R root:www-data /var/www
RUN chmod u+rwx,g+rx,o+rx /var/www
RUN find /var/www -type d -exec chmod u+rwx,g+rx,o+rx {} +
RUN find /var/www -type f -exec chmod u+rw,g+rw,o+r {} +
#essentially: CMD ["/usr/sbin/apache2ctl", "-D", "FOREGROUND"]
CMD ["/tmp/start.sh"]
However, when I build the container and run it, I only ever get 403 errors.
Notice that I've specified that Apache should run as www-data in www-data group, and that /var/www has been recursively chownd to belong to root:www-data.
Also, all directories are searchable and readable, and all files are readable and writeable by the www-data group (well, according to ls -la and namei -m they are anyways).
How do I fix these permissions issues? I cant figure it out.
Actual error from the Apache error.log:
[Fri May 23 18:33:27.663087 2014] [core:error] [pid 14] (13)Permission denied: [client 11.11.11.11:61689] AH00035: access to /index.php denied (filesystem path '/var/www/index.php') because search permissions are missing on a component of the path
EDIT:
output of ls -laR /var/www at the end of the Dockerfile:
Step 21 : RUN ls -laR /var/www
---> Running in 74fd3609dfc8
/var/www:
total 1036
drwxr-xr-x 67 root www-data 4096 May 23 18:38 .
drwxr-xr-x 26 root root 4096 May 23 18:38 ..
-rw-rw-r-- 1 root www-data 28 May 23 12:22 .gitignore
-rw-rw-r-- 1 root www-data 501 May 23 12:22 .htaccess
-rw-rw-r-- 1 root www-data 7566 May 23 12:22 index.php
Output of namei -m /var/www/index.php at the end of the Dockerfile:
Step 22 : RUN namei -m /var/www/index.php
---> Running in 1203f0353090
f: /var/www/index.php
drwxr-xr-x /
drwxr-xr-x var
drwxr-xr-x www
-rw-rw-r-- index.php
EDIT2
After trying a whole bunch of things, including chmod -R 777 just to see if I could get anything to work, I tried putting the source files added from the Dockerfile into /var/www/html, the default location for Apache files to be served.
I matched the default file permissions exactly (I think), and it still isn't working. The default index.html that comes with Apache loads just fine, but the added src folder still have a 403 access denied error.
I changed the Dockerfile to ADD src /var/www/html/src and the permissions were set using:
RUN find /var/www/html -type d -exec chmod u+rwx,g+rx,o+rx {} +
RUN find /var/www/html -type f -exec chmod u+rw,g+r,o+r {} +
No luck. Below is some of the output of ls -laR on /var/www. Notice that the permissions for the html folder and index.html that come with an apache2 install match those of the added src folder:
Step 19 : RUN ls -laR /var/www/
---> Running in 0520950d0426
/var/www/:
total 12
drwxr-xr-x 6 root root 4096 May 23 19:23 .
drwxr-xr-x 24 root root 4096 May 23 19:23 ..
drwxr-xr-x 5 root root 4096 May 23 19:23 html
/var/www/html:
total 24
drwxr-xr-x 5 root root 4096 May 23 19:23 .
drwxr-xr-x 6 root root 4096 May 23 19:23 ..
-rw-r--r-- 1 root root 11510 May 23 18:28 index.html
drwxr-xr-x 47 root root 4096 May 23 19:23 src
/var/www/html/src:
total 1032
drwxr-xr-x 47 root root 4096 May 23 19:23 .
drwxr-xr-x 5 root root 4096 May 23 19:23 ..
-rw-r--r-- 1 root root 28 May 23 12:22 .gitignore
-rw-r--r-- 1 root root 501 May 23 12:22 .htaccess
-rw-r--r-- 1 root root 7566 May 23 12:22 index.php
Perhaps chmod doesn't work quite the way I thought it does??
EDIT3
A final bit of information. The Docker container is being built by buildbot, which I've been assuming runs as root. I haven't been able to reproduce this scenario without using buildbot to do the building.
Building everything via sudo docker build -t apache . type commands on my laptop works fine, but the problems arise when buildbot does it. No idea why :^/
I just ran into this after posting a similar question at Running app inside Docker as non-root user.
My guess is you can't chmod/ chown files that were added via the ADD command. – thom_nic Jun 19 at 14:14
Actually you can. You just need to issue a a RUN command after the ADD for the file location that will be INSIDE your container. For example
ADD extras/dockerstart.sh /usr/local/servicemix/bin/
RUN chmod 755 /usr/local/bin/dockerstart.sh
Hope that helps. It worked for me.
I encountered a similar issue; however my container was using VOLUME to map directories across the container.
Changing the permissions on the directory that maps to /var/www/html itself remedied the 403 Forbidden errors.
docker-host$ ls -ld /var/www/html
drwxr--r-- 53 me staff 1802 Mar 8 22:33 .
docker-host$ chmod a+x /var/www/html
docker-host$ ls -ld /var/www/html
drwxr-xr-x 53 me staff 1802 Mar 8 22:33 .
Note that chmod must be applied on the Docker host, not within the container. Executing it within the container effects no change to the directory.
docker-container$ chmod a+x /var/www/html
docker-container$ ls -ld /var/www/html
drwxr--r-- 53 me staff 1802 Mar 8 22:33 .
I have a django application which should read and write to a crontab. However if I create the file with this:
sudo su www-data
crontab -e
I can see that:
# ls -la
total 12
drwx-wx--T 2 root crontab 4096 Aug 13 16:28 .
drwxr-xr-x 5 root root 4096 May 1 2012 ..
-rw------- 1 www-data crontab 202 Aug 13 16:28 www-data
However the file is still not readable and writeable by django. If I switch with sudo to www-data user I can't edit the file. How to setup the permissions properly?
You are not allowed to read that dir, for good reason.
You can however:
Read the file with crontab -l
Replace the crontab with crontab /path/to/file/which/will/replace/it.
So a workable solution would be:
Store current crontab -l in some tempfile.
Do you modifications on that tempfile
Install that tempfile with crontab /path/to/tempfile
The reason is in man cron:
Users are not allowed to edit the files under that directory
directly to ensure that only users allowed by the system to run periodic tasks can add them, and only syntactically correct crontabs will be written
there. This is enforced by having the directory writable only by the crontab group and configuring crontab command with the setgid bid set for that
specific group.