Hey Tim!! Thanks so much for the replies. This is exactly what I was hoping to find.Someone willing to kind of add to my lack of knowledge.
Your comments about copying files .vs moving files was/is gold. That's the kind of thing that wouldn't have crossed my mind to even think about. I'm not looking at fedora/centos as a sysAdmin. I'm coming at the OS as a means to get something done, and to move on to my next 99 things. That said, rather than have selinux in permissive/off, I'm willing to spend a bit of time to figure out/undertand some of the nuances. Here's my use case:: Test VM/web server runs httpd/apache web process runs php/py apps as webapps, under the /var/www/html/cat dir/tree structure -has multiple test users -treat the test users as "dev" users dev users are able to ssh/scp files into their home dir dev users able to copy/mv files from home dir to httpd dir structure might need to be able to rsync files from a dev users local env into the test "www/var/html" dir/tree I'm looking to be able to "set" up the test VM to have the dev, as well as the web processes/apps to be able to run correctly for test dev user 'bob' bob would have a "/home/bob" dir bob could scp files from an outside box into the VM. The files would reside in the /home/bob/foo dir -bob could then copy/mv the files into the /var/www/html/cat location would anything have to be done from a selinux perspective to permit the above to happen? My use case has potential devs copying code into the test VM to then run the webapps via httpd/apache I was initially thining that my issue was how to allow a "dev" user get files they work on into the docRoot space for the test webApps. I'm now thinking that the issue is really, how I allow the devs to get the files into the docRoot space, as well as "restrict" the ability for the dev to access other "stuff" on the VM.. I was thinking that using "groups" combined with selinux could accomplish this. Thoughts/Comments ps: Tim, if I back up and take a higher level view, but a bit more complex I think the "best" approach is to have a really basic dev/test VM, as well as a "Prod" VM. the "dev/test" VM environment might consist of test apache/httpd test mysql test dev tools php/py/etc test backup/verson control processes test dev/users The idea being that the "dev" would access the VM, work on the code, test the code, etc and be able to get the code ready for the "Prod" VM. Once the test/dev code is ready to be released, the code could somehow be "pushed" over to the "Prod" VM. This method would still have to resolve the management of user access, as well as process access. I'd still need to understand selinux and how it "works". On Wed, Apr 15, 2020 at 4:25 AM Tim via users <users@lists.fedoraproject.org> wrote: > On Tue, 2020-04-14 at 14:01 -0400, bruce wrote: > > I've already got the VM, test users, httpd, etc.. And things run with > > selinux disabled. > > > > Now it's time to take the jump, and engage selinux! > > Actually, that's going to be your biggest problem. If you've set up > and run things with it off, you're going to have to relabel your files > because SELinux wouldn't have been labelling them while it was off. > > The simplest way to do that is to relabel the entire filesystem, rather > than try and figure out what needs fixing. > > Generally speaking, things just work with SELinux engaged. I haven't > disabled it in years, not even for tests. Where you come a cropper is > when you want to do things outside of the norm, or you use software > that wants to do so. Since your concern is with web serving, I'll > point out that attitude is/was common with web-blogging that uses a > database style of webserving. While I seem to recall seeing that you'd > spoken of flat file webserving (where SELinux isn't a problem), I see > you mentioning PHP, which is typically used for fancier webserving. > > You may want to research PHP and SELinux, as a combined topic. > > In years gone past, it was not uncommon advise to switch off firewalls, > and other protective processes, from the *authors* of software, not > just users fumbling around in the dark. Simply because they didn't > understand security, wanted to do things that were unsafe, and didn't > want to change their mindset. > > Try to avoid that, try to learn how to correctly program and use PHP so > that it's not required. Don't let web things run as root, or have > world-writable permissions. Don't put website database files where > they can be directly accessed without using your PHP interfaces. > > -- > > uname -rsvp > Linux 3.10.0-1062.18.1.el7.x86_64 #1 SMP Tue Mar 17 23:49:17 UTC 2020 > x86_64 > > Boilerplate: All unexpected mail to my mailbox is automatically deleted. > I will only get to see the messages that are posted to the mailing list. > > _______________________________________________ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org >
_______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
