Re: bindfs for web docroot - is this sane?
On Wed, Oct 12, 2022 at 04:09:41PM +1300, Richard Hector wrote: > On 12/10/22 00:26, Dan Ritter wrote: [...] > > The better solution is to use a versioning system -- git is the > > default these days [...] > I agree that a git-based deployment scheme would be good. However, I > understand that it's considered bad practice for the docroot to itself be a > git repo, which means writing scripts to check out the right version and > then deploy it (which might also help with setting the right permissions). I think this is the wrong answer, too. Git is for developers, and as far as I understood Richard, the web server has to have write access to parts of the doc tree, on behalf of the users "out there" [1], and Richard wants a bit more of control over that. Barring some web site software using git as their backend, git seems the wrong "solution" for that. Cheers [1] PHP, sigh. -- t signature.asc Description: PGP signature
Re: bindfs for web docroot - is this sane?
On Wed, Oct 12, 2022 at 03:55:03PM +1300, Richard Hector wrote: > On 11/10/22 22:40, hede wrote: > > On 11.10.2022 10:03 Richard Hector wrote: > > > [...] > > > Then for site developers (who might be contractors to my client) to be > > > able to update teh site, they need read/write access to the docroot, > > > but I don't want them all logging in using the same > > > account/credentials. > > > [...] > > > Does that sound like a sane plan? Are there gotchas I haven't spotted? > > > > I think I'm not able to assess the bind-mount question, but... > > Isn't that a use case for ACLs? (incl. default ACLs for the webservers > > user here?) > > Yes, probably. However, I looked at ACLs earlier (months ago at least), and > they did my head in ... I haven't thought that through, but I think ACLs solve a slightly different problem. Cheers -- t signature.asc Description: PGP signature
Re: bindfs for web docroot - is this sane?
On 12/10/22 00:26, Dan Ritter wrote: Richard Hector wrote: Hi all, I host a few websites, mostly Wordpress. I prefer to have the site files (mostly) owned by an owner user, and php-fpm runs as a different user, so that it can't write its own code. For uploads, those directories are group-writeable. Then for site developers (who might be contractors to my client) to be able to update teh site, they need read/write access to the docroot, but I don't want them all logging in using the same account/credentials. So I've set up bindfs ( https://bindfs.org/ ) with the following fstab line (example at this stage): /srv/wptest-home/doc_root /home/richard/wptest-home/doc_root fuse.bindfs --force-user=richard,--force-group=richard,--create-for-user=wptest-home,--create-for-group=wptest-home 0 0 That means they can see their own 'view' of the docroot under their own home directory, and they can create files as needed, which will have the correct owner under /srv. I haven't yet looked at what happens with the uploaded and cached files which are owned by the php user; hopefully that works ok. This means I don't need to worry about sudo and similar things, or chown/chgrp - which in turn means I should be able to offer sftp as an alternative to full ssh logins. It can probably even be chrooted. Does that sound like a sane plan? Are there gotchas I haven't spotted? That's a solution which has worked in similar situations in the past, but it runs into problems with accountability and debugging. The better solution is to use a versioning system -- git is the default these days, subversion will certainly work -- and require your site developers to make their changes to the version controlled repository. The repo is either automatically (cron, usually) or manually (dev sends an email or a ticket) updated on the web host. I agree that a git-based deployment scheme would be good. However, I understand that it's considered bad practice for the docroot to itself be a git repo, which means writing scripts to check out the right version and then deploy it (which might also help with setting the right permissions). I'm also not entirely comfortable with either a cron or ticket-based trigger - I'd want to look into either git hooks (but that's on the wrong machine), or maybe a webapp with a deploy button. And then there's the issue of what is in git and what isn't, and how to customise the installation after checkout - eg setting the site name/url to distinguish it from the dev/staging site or whatever, setting db passwords etc. More stuff for the deployment script to do, I guess. So I like this idea, but it's a lot more work. And I have to convince my clients and/or their devs to use it, which might require learning git. And I'm not necessarily good enough at git myself to do that teaching well. - devs don't get accounts on the web host at all They might need it anyway, for running wp cli commands etc (especially given the privilege separation which means that installing plugins via the WP admin pages won't work - or would you include the plugins in the git repo?) - you can resolve the conflicts of two people working on the same site True. - automatic backups, assuming you have a repo not on this server I have backups of the web server; backups of the repo as well would be good. - easy revert to a previous version True. - easy deployment to multiple servers for load balancing True, though I'm not at that level at this point. Drawbacks: - devs have to have a local webserver to test their changes Yes, or a dev server/site provided by me - devs have to follow the process And have to know how, yes - someone has to resolve conflicts or decide what the deployed version is True anyway Note that this method doesn't stop the dev(s) using git anyway. In summary, I think I want to offer a git-based method, but I think it would work ok in combination with this, which is initially simpler. It sounds like there's nothing fundamentally broken about it, at least :-) Cheers, Richard
Re: bindfs for web docroot - is this sane?
On 11/10/22 22:40, hede wrote: On 11.10.2022 10:03 Richard Hector wrote: [...] Then for site developers (who might be contractors to my client) to be able to update teh site, they need read/write access to the docroot, but I don't want them all logging in using the same account/credentials. [...] Does that sound like a sane plan? Are there gotchas I haven't spotted? I think I'm not able to assess the bind-mount question, but... Isn't that a use case for ACLs? (incl. default ACLs for the webservers user here?) Yes, probably. However, I looked at ACLs earlier (months ago at least), and they did my head in ... Files will then still be owned by the user who created them. But your default-user has all (predefined) rights on them. Having them owned by the user that created them is good for accountability, but bad for glancing at ls output to see if everything looks right. I'd probably prefer that because - by instinct - I have a bad feeling regarding security if one user can slip/foist(?) a file to be "created" by some other user. But that's only a feeling without knowing all the circumstances. They can only have it owned by one specific user, but I acknowledge possible issues there. And this way it's always clear which users have access by looking at the ACLs while elsewhere defined bind mount commands are (maybe) less transparent. And you always knows who created them, if something goes wrong, for example. Nothing is clear to me when I look at ACLs :-) I do have the output of 'last' (for a while) to see who is likely to have created them. On the other hand, if you know of a good resource for better understanding ACLs, preferably with examples that are similar to my use case, I'd love to see it :-) ?) I'm not native English and slip or foist are maybe the wrong terms / wrongly translated. The context is that one user creates files and the system marks them as "created by" some other user. Seem fine to me :-) But they're owned by the other user; I wouldn't assume that that user created them. Especially when that user isn't directly a person. Thanks, Richard
Re: bindfs for web docroot - is this sane?
Richard Hector wrote: > Hi all, > > I host a few websites, mostly Wordpress. > > I prefer to have the site files (mostly) owned by an owner user, and php-fpm > runs as a different user, so that it can't write its own code. For uploads, > those directories are group-writeable. > > Then for site developers (who might be contractors to my client) to be able > to update teh site, they need read/write access to the docroot, but I don't > want them all logging in using the same account/credentials. > > So I've set up bindfs ( https://bindfs.org/ ) with the following fstab line > (example at this stage): > > /srv/wptest-home/doc_root /home/richard/wptest-home/doc_root fuse.bindfs > --force-user=richard,--force-group=richard,--create-for-user=wptest-home,--create-for-group=wptest-home > 0 0 > > That means they can see their own 'view' of the docroot under their own home > directory, and they can create files as needed, which will have the correct > owner under /srv. I haven't yet looked at what happens with the uploaded and > cached files which are owned by the php user; hopefully that works ok. > > This means I don't need to worry about sudo and similar things, or > chown/chgrp - which in turn means I should be able to offer sftp as an > alternative to full ssh logins. It can probably even be chrooted. > > Does that sound like a sane plan? Are there gotchas I haven't spotted? That's a solution which has worked in similar situations in the past, but it runs into problems with accountability and debugging. The better solution is to use a versioning system -- git is the default these days, subversion will certainly work -- and require your site developers to make their changes to the version controlled repository. The repo is either automatically (cron, usually) or manually (dev sends an email or a ticket) updated on the web host. Benefits: - devs don't get accounts on the web host at all - you can resolve the conflicts of two people working on the same site - automatic backups, assuming you have a repo not on this server - easy revert to a previous version - easy deployment to multiple servers for load balancing Drawbacks: - devs have to have a local webserver to test their changes - devs have to follow the process - someone has to resolve conflicts or decide what the deployed version is -dsr-
Re: bindfs for web docroot - is this sane?
On 11.10.2022 10:03 Richard Hector wrote: [...] Then for site developers (who might be contractors to my client) to be able to update teh site, they need read/write access to the docroot, but I don't want them all logging in using the same account/credentials. [...] Does that sound like a sane plan? Are there gotchas I haven't spotted? I think I'm not able to assess the bind-mount question, but... Isn't that a use case for ACLs? (incl. default ACLs for the webservers user here?) Files will then still be owned by the user who created them. But your default-user has all (predefined) rights on them. I'd probably prefer that because - by instinct - I have a bad feeling regarding security if one user can slip/foist(?) a file to be "created" by some other user. But that's only a feeling without knowing all the circumstances. And this way it's always clear which users have access by looking at the ACLs while elsewhere defined bind mount commands are (maybe) less transparent. And you always knows who created them, if something goes wrong, for example. regards hede ?) I'm not native English and slip or foist are maybe the wrong terms / wrongly translated. The context is that one user creates files and the system marks them as "created by" some other user.
