what can cause a socket() "Permission denied" error? - permissions

Under Android 4, the following simple native C code line fails with an Permission denied error when not run as root:
online_socket = socket(AF_INET, SOCK_DGRAM, 0);
I do have root access to the device, but want to run the process as non-privileged user.
Note that the error happens even before binding the socket.
I guess there is some security setting that needs to be tweaked? Anyone can tell me where to look?
The O/S is really Android in this case, but I guess the problem is really Linux-related (since Android is based on a Linux Kernel).
For those wondering: This is a custom program that runs in a full (debootstrapped) Debian Jessie installation running in an Android 4 environment.
Update
I've learned that the Android Kernel has a special CONFIG_ANDROID_PARANOID_NETWORK extension that allows network access only to users in AID_INET and AID_NET_RAW groups.
However, even after adding the user to these groups, socket() is still rejected (and ping appears to have the same problem, BTW).
uid=5(imp) gid=51(imp) groups=51(imp),3003(aid_inet),3004(aid_net_raw),3005(aid_admin),3001(aid_bt),3002(aid_bt_net)
I can't tell if that CONFIG_ANDROID_PARANOID_NETWORK flag is set in this particular Kernel, as I don't have access to the config file.
Update 2
I found out that both root and also my unprivileged user imp can in fact successfully call socket() - at least with the groups setup described above.
However, calling the same process as root and then switching to imp using the seteuid() system call prevents socket() from succeeding. Any ideas?

As it turns out, Android uses a special Kernel patch that's activated with CONFIG_ANDROID_PARANOID_NETWORK. This patch allows network access to system users that belong to certain special groups with hardcoded IDs.
groupadd -g 3001 aid_bt
groupadd -g 3002 aid_bt_net
groupadd -g 3003 aid_inet
groupadd -g 3004 aid_net_raw
groupadd -g 3005 aid_admin
That's because Android normally adds users (i.e. apps) to these groups only when the specific app has networking permissions.
Adding a user to these groups gives it permission to use socket() as described in the question:
usermod -a -G aid_bt,aid_bt_net,aid_inet,aid_net_raw,aid_admin someuser
However, when a process uses seteuid() to switch from root to a unprivileged user (for example someuser), then it's not enough (or probably irrelevant) that this effective user has aid_* group membership. Instead, the root user must explicitly be a member of these groups:
usermod -a -G aid_bt,aid_bt_net,aid_inet,aid_net_raw,aid_admin root
This solved the problem for me.
Note that I've also tried to play with setegid() and similar as an alternative, but none of that helped...

Those who struggle with the apt-get on Android (with the CONFIG_ANDROID_PARANOID_NETWORK enabled which restricts network access to users who are member of specific groups) there are two workaround:
groupadd -g 3003 aid_inet && usermod -G nogroup -g aid_inet _apt
echo 'APT::Sandbox::User "root";' > /etc/apt/apt.conf.d/01-android-nosandbox
This is because apt-get is running http/https/gpgv methods under a sandboxed user, which is _apt by default:
root 1465 0.0 0.0 31408 4956 pts/0 S 11:48 0:00 | | \_ -bash
root 23814 0.1 0.1 65300 10124 pts/0 T 18:58 0:00 | | \_ apt-get update
_apt 23818 0.0 0.1 90208 8852 pts/0 T 18:58 0:00 | | | \_ /usr/lib/apt/methods/http
_apt 23819 0.0 0.1 90208 8828 pts/0 T 18:58 0:00 | | | \_ /usr/lib/apt/methods/https
...

Related

Homebrew Apache directories on MacOS Big Sur

I went thru any tutorial I could find to install and configure Apache on Big Sur. Invariably, the tutorial when discussing the config files will point to /usr/local/etc/httpd/httpd.conf that needs to be massaged a bit. The only trouble is that the file doesn't exist when I check that dir. Any idea? Thanks for your help in advance.
EDIT: I did an uninstall and install of httpd per requested and I still don't get the /usr/local/. There must be something different the homebrew configuration.
➜ ~ brew uninstall httpd
Uninstalling /opt/homebrew/Cellar/httpd/2.4.49... (1,660 files, 31.9MB)
➜ ~ brew install httpd
==> Downloading https://ghcr.io/v2/homebrew/core/httpd/manifests/2.4.49
Already downloaded: /Users/johnny/Library/Caches/Homebrew/downloads/6c60d66c3915be5c993e144a743960b9e6be26e557efeeb6c61f530c79ffed34--httpd-2.4.49.bottle_manifest.json
==> Downloading https://ghcr.io/v2/homebrew/core/httpd/blobs/sha256:e6ebcb4a1307
Already downloaded: /Users/johnny/Library/Caches/Homebrew/downloads/8506f199d5d7def536481d6fa87aa94c25201b57072d032e97edb8ce78fa86a3--httpd--2.4.49.arm64_big_sur.bottle.tar.gz
==> Pouring httpd--2.4.49.arm64_big_sur.bottle.tar.gz
==> Caveats
DocumentRoot is /opt/homebrew/var/www.
The default ports have been set in /opt/homebrew/etc/httpd/httpd.conf to 8080 and in
/opt/homebrew/etc/httpd/extra/httpd-ssl.conf to 8443 so that httpd can run without sudo.
To restart httpd after an upgrade:
brew services restart httpd
Or, if you don't want/need a background service you can just run:
/opt/homebrew/opt/httpd/bin/httpd -D FOREGROUND
==> Summary
🍺 /opt/homebrew/Cellar/httpd/2.4.49: 1,660 files, 31.9MB
➜ ~
[Edited and updated]
I am using macOS Catalina 10.15.7 / Xcode-select version 2373 and by running $ brew install httpd I can install the Apache service under /usr/local/
Can you please remove and install it again by using the same command and sharing all the output?
These are the important things:
DocumentRoot is /usr/local/var/www.
The default ports have been set in /usr/local/etc/httpd/httpd.conf to 8080 and in
/usr/local/etc/httpd/extra/httpd-ssl.conf to 8443 so that httpd can run without sudo.
To start httpd:
brew services start httpd
Or, if you don't want/need a background service you can just run:
/usr/local/opt/httpd/bin/httpd -D FOREGROUND
This is the list of directories.
$ ls -lrt /usr/local/etc/httpd
total 200
drwxr-xr-x 14 user admin 448 Sep 22 23:35 extra
-rw-r--r-- 1 user admin 21222 Sep 22 23:35 httpd.conf
-rw-r--r-- 1 user admin 13064 Sep 22 23:35 magic
-rw-r--r-- 1 user admin 60847 Sep 22 23:35 mime.types
drwxr-xr-x 4 user admin 128 Sep 22 23:35 original
And this is my test showing it is working.
$ curl localhost:8080
<html><body><h1>It works!</h1></body></html>
$ tail -f /usr/local//var/log/httpd/access_log
::1 - - [22/Sep/2021:23:39:35 -0500] "GET / HTTP/1.1" 200 45
Based on your output and the brew documentation I believe you are using Apple Silicon is that correct, can you confirm?
https://docs.brew.sh/Installation
This script installs Homebrew to its preferred prefix (/usr/local for macOS Intel, /opt/homebrew for Apple Silicon, and /home/linuxbrew/.linuxbrew for Linux) so that you don’t need sudo when you brew install. It is a careful script; it can be run even if you have stuff installed in the preferred prefix already. It tells you exactly what it will do before it does it too. You have to confirm everything it will do before it starts.

Composer Akeneo installation Could not open input file composer.phar

I am trying to install a PIM named Akeneo. The system requirements are all checked:
https://docs.akeneo.com/2.3/install_pim/manual/system_requirements/system_requirements.html
I am on Apache2 / Ubuntu 16.04
My /var/www/ directory all belongs to www-data:www-data ( ran chown -R www-data:www-data to install )
Error message from server : “Could not open input file: composer.phar”
Googled about it , got many results, and looked on the forums on stakoverflow, found answers from 2010 to 2018. I think I have maybe found out that the problem could be linked with the file "composer.phar", the way symlinks work on apache2, and composer installed globally or "inside individual project(s)".
Following 2 tutorials, I had to install composer to continue the install for that PIM.
My server says:
Composer (version 1.10.10) successfully installed to:
/usr/local/bin/composer
If I navigate to cd ~ and run ls I see there is "composer.phar" and "composer-setup.php" here.
I am confused because the Akeno tutorial says:
After extracting the file, change into the Akeneo directory and run
the commands below:
cd /var/www/html/akeneo/pim-community-standard
sudo php -d memory_limit=3G ../composer.phar install --optimize-autoloader --prefer-dist
sudo php bin/console cache:clear --no-warmup --env=prod
...
I don't understand the composer.phar install part . There are no composer.phar file inside any directories : not in /var/www/html/akeneo/ and not in /var/www/html/akeneo/pim-community-standard
Was it supposed to generate a composer.phar file there ? Should it find composer.phar one level above ( ../composer.phar ) ? I doubled checked the Akeneo PIM files , and the original .rar archive has no composer.phar file. Or, is it something to do with a symlink that accesses the global "composer.phar" which was with the global install ? Regarding symlinks, there are some in the "vendor" fodler of the PIM, and runing ls -l -a gives :
lrwxrwxrwx 1 www-data www-data 28 Feb 5 2020 doctrine -> ../doctrine/orm/bin/doctrine
lrwxrwxrwx 1 www-data www-data 34 Feb 5 2020 doctrine-dbal -> ../doctrine/dbal/bin/doctrine-dbal
lrwxrwxrwx 1 www-data www-data 46 Feb 5 2020 doctrine-migrations -> ../doctrine/migrations/bin/doctrine-migrations
lrwxrwxrwx 1 www-data www-data 56 Feb 5 2020 requirements-checker -> ../symfony/requirements-checker/bin/requirements-checker
lrwxrwxrwx 1 www-data www-data 51 Feb 5 2020 var-dump-server -> ../symfony/var-dumper/Resources/bin/var-dump-server
There is a composer.json and composer.lock file inside /var/www/html/akeneo/pim-community-standard . So confused because the turorial says to be inside pim-community-standard directory and run this : php -d memory_limit=3G ../composer.phar install --optimize-autoloader --prefer-dist
I hope I can resume the install without breaking anything. Some posts give the solution of updating composer, or installing composer-phar, inside the project. I am honestly totally lost.
( I don't know if I should bring that up, but is docker needed (not talked about in tutorial - but I see a folder with "docker" in it and I know that composer and docker can work together sometimes )
I moved the composer.phar file into the app directory. Now the install advanced. It's not a technical issue a misconfiguration or anything like that.
It's a lack of information about Composer on the Akeneo site but it's probably assumed that users should have knowledge about Composer allready.
Solution for me : moving the "composer.phar" file (from 'home' for me ) to the /var/www/project/ (.. the correct level directory).
So for my case it was a global / local install issue , which is still unclear, and I will have to look deeper how to properly install composer. Not sure if my current setup will not cause any issue later since it's like I installed it globally at first then moved only one file.
Also, command "composer" is not returning anything. I do have the composer file in /usr/bin/ though. This is very strange.

why lxc command gives me permission denied error?

I have some problem in executing command lxc. when i try without sudo i get the error:
$ lxc storage list
Error: Get http://unix.socket/1.0: dial unix /var/snap/lxd/common/lxd/unix.socket: connect: permission denied
when i try with sudo i get:
$ sudo lxc storage list
sudo: lxc: command not found
i don't understand the problem about permission and i cannot solve this type of issue. Any suggestion is appreciated
INFO: i'm runnign Debian 10 buster on a virtual machine, i installed lxd and lxc by:
$ sudo snap install lxd
$ sudo apt install lxc
modified PATH with:
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/snap/bin:/snap/bin:/var/lib/snapd/snap/bin:/snap/bin/lxc:/snap/bin/lxd
i added my account to sudoers:
moro ALL=(ALL)ALL
if i run
$ su-
root#debian:~# lxc storage list
+---------+-------------+--------+--------------------------------------------+---------+
| NAME | DESCRIPTION | DRIVER | SOURCE | USED BY |
+---------+-------------+--------+--------------------------------------------+---------+
| default | | btrfs | /var/snap/lxd/common/lxd/disks/default.img | 14 |
+---------+-------------+--------+--------------------------------------------+---------+
As far as my understanding goes, lxc uses the lxc group, in which your $USER has to be. Thus everything should work as expected if you add your user to the lxc group, e.g. via
sudo adduser $USER lxd
This is mentioned without an example on the lxd page getting started under access control and with an example in this
nice tutorial for Ubuntu 16.04, which should be applicable to many other debian based OS.

Docker - non-privileged user can write to / inside container

I've created a container, based off the centos:6.8 image using the following Dockerfile:
FROM centos:6.8
RUN adduser -m test
USER test
The image is then built using docker build:
docker build -t dockerdemo .
Then I start a container with:
docker run -ti dockerdemo bash
When I am inside the container, I appear to be able to write as the "test" user into the root directory of the container:
[test#9af9c4aeb990 /]$ ls -ld /
drwxr-xr-x 29 root root 4096 Oct 25 09:49 /
[test#9af9c4aeb990 /]$ id -a
uid=500(test) gid=500(test) groups=500(test)
[test#9af9c4aeb990 /]$ touch /test-file
[test#9af9c4aeb990 /]$ ls -l /test-file
-rw-rw-r-- 1 test test 0 Oct 25 09:49 /test-file
I am expecting to see Permission denied when I run the touch command.
If I alter the Dockerfile and remove the USER statement, and rebuild, then I can su to the "test" user inside the container and I get the behaviour I would expect:
[root#d16277f693d8 /]# su - test
[test#d16277f693d8 ~]$ id
uid=500(test) gid=500(test) groups=500(test)
[test#d16277f693d8 ~]$ ls -ld /
drwxr-xr-x 29 root root 4096 Oct 25 09:50 /
[test#d16277f693d8 ~]$ touch /test-file
touch: cannot touch `/test-file': Permission denied
Have I misunderstood how user permissions work inside containers?
Is there a way to produce my expected behaviour?
There was a vulnerability announced in 1.12.2 that your scenario matches. Release 1.12.3 just came out yesterday to fix this issue and CVE-2016-8867 was registered on the vulnerability. It's an internal container privilege escalation, so limited impact, but still worth the upgrade.

Can't open file 'svn/repo/db/txn-current-lock': Permission denied

I have set up a Linux Server and installed Apache and SVN and dav_svn on it. Now, when I try to upload to https://x.x.x.x:x/svn/repo with Tortoise SVN I get
Can't open file '/server/svn/repo/db/txn-current-lock': Permission denied
I have Set up my SSL correctly (I can checkout, no problems, even remotely due to Port Forwarding).
I'm guessing this has to do with the Linux Ownership of the Repository folders, How must I set this/ what are the commands?
This is a common problem. You're almost certainly running into permissions issues. To solve it, make sure that the apache user has read/write access to your entire repository. To do that, chown -R apache:apache *, chmod -R 664 * for everything under your svn repository.
Also, see here and here if you're still stuck.
Update to answer OP's additional question in comments:
The "664" string is an octal (base 8) representation of the permissions. There are three digits here, representing permissions for the owner, group, and everyone else (sometimes called "world"), respectively, for that file or directory.
Notice that each base 8 digit can be represented with 3 bits (000 for '0' through 111 for '7'). Each bit means something:
first bit: read permissions
second bit: write permissions
third bit: execute permissions
For example, 764 on a file would mean that:
the owner (first digit) has read/write/execute (7) permission
the group (second digit) has read/write (6) permission
everyone else (third digit) has read (4) permission
Hope that clears things up!
It's permission problem. It is not "classic" read/write permissions of apache user, but selinux one.
Apache cannot write to files labeled as httpd_sys_content_t they can be only read by apache.
You have 2 possibilities:
label svn repository files as httpd_sys_content_rw_t:
chcon -R -t httpd_sys_content_rw_t /path/to/your/svn/repo
set selinux boolean httpd_unified --> on
setsebool -P httpd_unified=1
I prefer 2nd possibility. You can play also with other selinux booleans connected with httpd:
getsebool -a | grep httpd
I also had this problem recently, and it was the SELinux which caused it.
I was trying to have the post-commit of subversion to notify Jenkins that the code has change so Jenkins would do a build and deploy to Nexus.
I had to do the following to get it to work.
1) First I checked if SELinux is enabled:
less /selinux/enforce
This will output 1 (for on) or 0 (for off)
2) Temporary disable SELinux:
echo 0 > /selinux/enforce
Now test see if it works now.
3) Enable SELinux:
echo 1 > /selinux/enforce
Change the policy for SELinux.
4) First view the current configuration:
/usr/sbin/getsebool -a | grep httpd
This will give you: httpd_can_network_connect --> off
5) Set this to on and your post-commit will work with SELinux:
/usr/sbin/setsebool -P httpd_can_network_connect on
Now it should be working again.
for example on debian
sudo gpasswd -a svn-admin www-data
sudo chgrp -R www-data svn/
sudo chmod -R g=rwsx svn/
I just had this problem
Having multiple user using the same repo caused the problem
Logout evey other user using the repo
Hope this helps
In addition to the repository permissions, the /tmp directory must also be writeable by all users.
3 Steps you can follow
chmod -R 775 <repo path>
---> change permissions of repository
chown -R apache:apache <repo path>
---> change owner of svn repository
chcon -R -t httpd_sys_content_t <repo path>
----> change SELinux security context of the svn repository
Try to disable SELinux by this command /usr/sbin/setenforce 0. In my case it solved the problem.