Open dshoreman opened 5 years ago
Would running a separate service (either as root, or in a restricted shell) that can be used by the the web application as a file-system read API, be out of scope?
@nCrazed No, quite the opposite! A completely seperate service/daemon running locally is the ideal solution (and long term plan) for a few things. This issue along with data collection for server resources (CPU activity, free space etc) are probably the two best examples.
I was thinking of using Golang or Elixir, but that's not set in stone yet. They would have the benefit of running as a standalone binary thus no need to mess about running artisan via PHP in a root cron or something like that. It would remove the need for modifications to /etc/sudoers
too, which is a massive bonus.
All that said, I haven't thought too much about actual implementations yet so I'm still open to any ideas you might have. One thing that does need to happen at some point is linking Servidor (app) users to a system (Linux) user account. That way in the future we'll be able to restrict access based on real permissions. In PHP that might be something like:
exec(sprintf('sudo -u %s ls -lA "%s"', $user->systemName, $path), $results);
Not pretty, but (likely) somewhat functional with some wrapping bits. Not really a high priority atm though as Servidor is mostly setup for single-user mode where said single user owns everything.
Super-long-term the biggest benefit to a service would be expansion. Currently if you have two servers, you need a full install on each which isn't ideal. It would be great if you could have one central 'hub' (ie the webapp) that any number of services can report to from various different servers.
Anywho, all just ideas at this point so I'd love to hear your thoughts! Sorry for the essay 😉
When you browse to somewhere like
/root
which doesn't have read permissions forwww-data
, it just throws a 500 and does nothing. If you try to load the page at a path without permission, it'll show a blank file list.There are probably other ways around it (at least I hope so), but for now we could do with manually parsing output from the
ls
command running as sudo. Same goes for opening files, too.Eventually paths should be checked for permissions before attempting to load anything within them. That'll have to happen when db users are linked to actual system users though - for now we assume superuser status.