snipe-it icon indicating copy to clipboard operation
snipe-it copied to clipboard
verified publisher icon snipe

permission denied unlinking app/backup-temp/db-dumps/mysql-snipeit.sql during ad-hoc backup run

Open bby-bishopclark opened this issue 3 years ago • 4 comments

Debug mode

Describe the bug

Hi Everyone,

When my peer goes to run a backup of his server, he's getting this weird error, as shown below.

When checking, I found that yes, it definitely IS a perms issue when the httpd (as apache:snipeitapp) creates the dump earlier (via cron?) but then can't remove it as apache:snipeitapp . Here's the current tree perms;

# namei -lx /usr/share/snipe-it/storage/app/backup*/temp/db*/my*                                                                                                                                                                                           f: /usr/share/snipe-it/storage/app/backup-temp/temp/db-dumps/mysql-snipeit.sql
Dr-xr-xr-x root       root       /
drwxr-xr-x root       root       usr
drwxr-xr-x root       root       share
drwxr-xr-x root       root       snipe-it
drwxrwsr-x apache     snipeitapp storage
drwxrwsr-x apache     snipeitapp app
drwxr-sr-x snipeitapp snipeitapp backup-temp
drwxr-sr-x snipeitapp snipeitapp temp
drwxr-sr-x snipeitapp snipeitapp db-dumps
-rw-r--r-- snipeitapp snipeitapp mysql-snipeit.sql

Obvious, right?

The question is, given roles must be separated, and given how the backup tree is maintained, would it make sense to encode a facl into /app/ so that backup-temp and friends get a 'chmod u+s' instead, or just a chmod u+s on the app dir and/or keep the current chmod g+s we have now? What's correct, given who the actor-user is doing the backup storage and cleanup?

Caveats o'plenty:

  • we're on RockyLinux (enterprise linux like RHEL or CentOS post-CentOS-dying) and it's all RPMs and it's an RPM I'm maintaining internally
  • I understand this puts me on the fringe
  • we cannot use composer in a production environment (see ISO-27002:12.5.1b)
  • our snipe-it is 5.3.10 since 5.3.11 and 5.4 aren't compatible with what enterprise linux provides (27002:14.2.4) so it's gonna be a little older than what we're used to. It's also got 2-3 backported security fixes.

Reproduction:

More than just a song in /grease2/, here's a vagrant, but I can't ship a binary because copr is hating the composer bit. So, build one yourself! Yay!

This vagrantfile will set up an EL8 box, build you the binary, install it, and try to start a webserver. But, sadly, my PoC is toast because the redirection seems to be fighting with the software's idea of itself and it's 302-ing localhost:8080 to a bogus URL. Another bug or my own misconfig? I don't know. I'm hoping there's enough here to help replicate the state of my guy's host as shown in the pic below so I can get a hint on that ownership. We can talk about how I fail at Vagrant in a related thread.

Is vagrant a suitable test deployment for poking at the software? Should I have replicated the state some other way?

image

Reproduction steps

  1. install compatible snipe-it package
  2. request an ad-hoc backup through the webUI
  3. observe ENOPERM issue ...

Expected behavior

Well, yeah, obviously, we want that backup created; safely and securely. ;-)

Screenshots

screenie is above.

Snipe-IT Version

snipe-it-5.3.10-2.el8.noarch

Operating System

rocky-release-8.7-1.2.el8.noarch

Web Server

httpd-2.4.37-51.module+el8.7.0+1059+126e9251.x86_64

PHP Version

php-common-7.2.24-1.module+el8.4.0+413+c9202dda.x86_64

Operating System

win10

Browser

chrome (up-to-date-ish)

Version

108.0.5359.100

Device

No response

Operating System

No response

Browser

No response

Version

No response

Error messages

#  php -m
[PHP Modules]
bcmath
bz2
calendar
Core
ctype
curl
date
dom
exif
fileinfo
filter
ftp
gd
gettext
hash
iconv
json
ldap
libxml
mbstring
mysqli
mysqlnd
openssl
pcntl
pcre
PDO
pdo_mysql
pdo_sqlite
Phar
posix
readline
Reflection
session
shmop
SimpleXML
sockets
SPL
sqlite3
standard
sysvmsg
sysvsem
sysvshm
tokenizer
wddx
xml
xmlreader
xmlwriter
xsl
zlib

[Zend Modules]

Additional context

  • upgraded several times
  • RPM installation (see build process above)
  • no known manual db edits

bby-bishopclark avatar Dec 15 '22 21:12 bby-bishopclark

👋 Thanks for opening your first issue here! If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.

welcome[bot] avatar Dec 15 '22 21:12 welcome[bot]

Well, first off, this is an absolutely fantastic bug report, so thank you!

As for you being on an older version, we've definitely run into a few issues with later versions of Laravel (and, thus, of Snipe-IT) requiring libsodium, and it not being available in highly restrictive environments. There is a polyfill that implements libsodium functionality in pure PHP - https://github.com/paragonie/sodium_compat - but that would again require you to run composer install which it sounds like you can't do in Prod. (Which is weird, in that I can't figure out how you got the software installed in the first place, but whatevs).

Docker might be another interesting way to go, perhaps?

Anywhoo, back to your permissions thing. I think the thing that prevents you from deleting the files is that the Apache group doesn't have write permissions on the various directories in question (though your Sticky bit ideas also sound pretty reasonable). You're going to want to be able to run backups as your Snipe-IT user (snipeitapp), or as your web server (apache group). If you did want to muck around with ACL's I bet those would work too, but I tend to not use them. Cron will often be configured to run backups on a schedule, as well as running cleanups of the backup directory. And you can also directly delete backups in the web interface, as well as creating them there.

So, see if you can give that a whirl. We'll definitely consider if we want to add the libsodium compatibility layer. It's allegedly far, far, far slower than "real" libsodium, but it should at least work. And we don't hit crypto primitives that hard, anyways. So it should be fine.

GitHub
Pure PHP polyfill for ext/sodium. Contribute to paragonie/sodium_compat development by creating an account on GitHub.

uberbrady avatar Dec 21 '22 17:12 uberbrady

require you to run composer install which it sounds like you can't do in Prod. (Which is weird, in that I can't figure out how you got the software installed in the first place, but whatevs).

Yeah, it seems janky. There's two issues we surmounted handily:

  1. we can't run composer in prod (ISO-27002:12.5.1b) - but we can run it in dev, package software in an atomically installable artefact, push that to prod and we're good. This is the way[tm].

  2. composer by that name on rhel8 is gone. We grabbed it from EL7, such an embarrassingly cheap hack, and ran it on 8. It's a noarch install, it comes from an approved supply, and it does the job. Now, I know something in the EL8 (and 9) distribution has something we can use instead, but I've not got the brain-power and time lined up at the same time (more kittens than ducks) to figure it out while the cheap hack works.

Docker might be another interesting way to go, perhaps?

Nope. It fails transparency and validation (Hint: it's HOST-RESOURCES-MIB::hrSWInstalledName or nothin). We could run tiny alpine VMs, but - yep - alpine requires an approval process, and it smells like a photon build or a really lean Enterprise Linux install anyway so it's hard to justify the labour.

To go over your solution in words small enough for my sleepy brain, then:

  1. modding the composer config will allow it to pull libsodium compat in, and build a newer Snipe-IT on an older PHP base (and replace the labour required to analyse and back-port fixes on a fork with something we can just consume again). That kindles some glee in my heart, so give me a nod as my Christmas present and I'm good.

  2. the chmod lets apache - which nginx runs php-fpm as on EL ; a different compatibility adventure - write the backup dir but not the actual installed code, which should make the security stay cool and still let my guy back up his db as often as he fancies. And there was much rejoicing. Am I close?

I really appreciate your time on this. As mentioned before, I totally get that our setup is fringey and weird, and I'm grateful for every thought and minute spent on this thing.

bby-bishopclark avatar Dec 22 '22 19:12 bby-bishopclark

Hi there - I know this is a pretty old issue, but I wanted to check and see if you ever got this resolved? If so, can you please close the ticket? If not, can you update us on what version of Snipe-IT you're currently using, so we can see if it's still an issue on latest?

:) Thanks!

snipe avatar Aug 11 '25 05:08 snipe