I've been trying to find a good solution to this problem for *years* but I'm still hitting problems with it. The current problem is that syncthing doesn't deal well with directories and files which have different owners on different systems.
The essential problem is that web files which are manipulated by apache need to be owned by www-data but I want to be able to edit these files as well. In particular I have a wiki where I sometimes edit the files using the wiki (ownership ends up as www-data) and sometimes I edit them directly with an editor (ownership ends up as chris).
Currently I use access control lists (setfacl) to make things so that both chris and www-data can both manipulate files in the wiki directory regardless of whether they are owned by chris or www-data but this isn't a perfect solution as the correct settings don't always get put on new files.
What I really need is:-
All the wiki files are owned by 'chris' (the wiki is rooted in my home directory and is synchronised across a couple of machines by syncthing).
www-data can read/write/create files in the ~/chris/wiki directory but they will always be owned by 'chris'.
Can anyone see a way of implementing this? ... or any other reasonable solution?
On 05/12/17 09:52, Chris Green wrote:
I've been trying to find a good solution to this problem for *years* but I'm still hitting problems with it. The current problem is that syncthing doesn't deal well with directories and files which have different owners on different systems.
The essential problem is that web files which are manipulated by apache need to be owned by www-data but I want to be able to edit these files as well. In particular I have a wiki where I sometimes edit the files using the wiki (ownership ends up as www-data) and sometimes I edit them directly with an editor (ownership ends up as chris).
Currently I use access control lists (setfacl) to make things so that both chris and www-data can both manipulate files in the wiki directory regardless of whether they are owned by chris or www-data but this isn't a perfect solution as the correct settings don't always get put on new files.
What I really need is:-
All the wiki files are owned by 'chris' (the wiki is rooted in my home directory and is synchronised across a couple of machines by syncthing). www-data can read/write/create files in the ~/chris/wiki directory but they will always be owned by 'chris'.Can anyone see a way of implementing this? ... or any other reasonable solution?
https://unix.stackexchange.com/questions/115631/getting-new-files-to-inherit...
Or change apache's user to chris, or use a file-system-modification watcher to look for new files and change their owner, or write a cron job or similar to regularly change the file ownership or....
you can do this with samba, you may be able to do this with some other "mount" options for other filesystems: move the wiki directory somewhere else. Use samba (or other) to mount it in the desired subdirectory, BUT use mount options to force user and group to be a specific user. That way, all newly created files will actually be owned by the correct user.
HTH
Steve
On Thu, Dec 07, 2017 at 10:47:28AM +0000, steve-ALUG@hst.me.uk wrote:
On 05/12/17 09:52, Chris Green wrote:
I've been trying to find a good solution to this problem for *years* but I'm still hitting problems with it. The current problem is that syncthing doesn't deal well with directories and files which have different owners on different systems.
The essential problem is that web files which are manipulated by apache need to be owned by www-data but I want to be able to edit these files as well. In particular I have a wiki where I sometimes edit the files using the wiki (ownership ends up as www-data) and sometimes I edit them directly with an editor (ownership ends up as chris).
Currently I use access control lists (setfacl) to make things so that both chris and www-data can both manipulate files in the wiki directory regardless of whether they are owned by chris or www-data but this isn't a perfect solution as the correct settings don't always get put on new files.
What I really need is:-
All the wiki files are owned by 'chris' (the wiki is rooted in my home directory and is synchronised across a couple of machines by syncthing). www-data can read/write/create files in the ~/chris/wiki directory but they will always be owned by 'chris'.Can anyone see a way of implementing this? ... or any other reasonable solution?
https://unix.stackexchange.com/questions/115631/getting-new-files-to-inherit...
Group permissions don't (quite) do it. The 'S' bit on group does this and it was my original attempt at handling the issue.
Or change apache's user to chris, or use a file-system-modification watcher to look for new files and change their owner, or write a cron job or similar to regularly change the file ownership or....
Changing the apache user to 'chris' would be a big risk IMHO, I don't want all and sundry on the web to have access to my files. Yes I know it's not this bad as I don't allow outside access to my web server and apache also limits access via its configuration but it's a risk I'd rather avoid.
I looked at the file system watcher approach, possible but would take quite a lot of work.
A cron job is certainly a possibility, it's simple and probably effective, the *only* issue is that it might lag behind reality a little depending on how often you run the cron job.
you can do this with samba, you may be able to do this with some other "mount" options for other filesystems: move the wiki directory somewhere else. Use samba (or other) to mount it in the desired subdirectory, BUT use mount options to force user and group to be a specific user. That way, all newly created files will actually be owned by the correct user.
I hadn't thought about this possibility, I'll look into what mount/samba might be able to do, though I don't like using samba/cifs if I can avoid it, I always find its ways rather arcane.
On Tue, 2017-12-05 at 09:52 +0000, Chris Green wrote:
The current problem is that syncthing doesn't deal well with directories and files which have different owners on different systems.
In which case you either need to replace syncthing, or give the directories and files the same owners on different systems!
On 07/12/17 11:00, Huge wrote:
On Tue, 2017-12-05 at 09:52 +0000, Chris Green wrote:
The current problem is that syncthing doesn't deal well with directories and files which have different owners on different systems.
In which case you either need to replace syncthing, or give the directories and files the same owners on different systems!
+1
If you are replicating files between systems, it does help to have the same usernames, groups, user numbers/ids and group ids, at least for users who have files on multiple machines.
Steve
On Thu, Dec 07, 2017 at 11:04:06AM +0000, steve-ALUG@hst.me.uk wrote:
On 07/12/17 11:00, Huge wrote:
On Tue, 2017-12-05 at 09:52 +0000, Chris Green wrote:
The current problem is that syncthing doesn't deal well with directories and files which have different owners on different systems.
In which case you either need to replace syncthing, or give the directories and files the same owners on different systems!
+1
If you are replicating files between systems, it does help to have the same usernames, groups, user numbers/ids and group ids, at least for users who have files on multiple machines.
Absolutely!!! That's what prompted the question, I'm *trying* to make things so that files are owned by 'chris' everywhere but the requirement to give www-data access as well makes that difficult.
On Thu, 2017-12-07 at 11:45 +0000, Chris Green wrote:
On Thu, Dec 07, 2017 at 11:04:06AM +0000, steve-ALUG@hst.me.uk wrote:
On 07/12/17 11:00, Huge wrote:
On Tue, 2017-12-05 at 09:52 +0000, Chris Green wrote:
The current problem is that syncthing doesn't deal well with directories and files which have different owners on different systems.
In which case you either need to replace syncthing, or give the directories and files the same owners on different systems!
+1
If you are replicating files between systems, it does help to have the same usernames, groups, user numbers/ids and group ids, at least for users who have files on multiple machines.
Absolutely!!! That's what prompted the question, I'm *trying* to make things so that files are owned by 'chris' everywhere but the requirement to give www-data access as well makes that difficult.
You need three UIDs to safely run a web server, and none of them should be "chris". The server itself should run as one UID, its configuration files should be owned by a second (so it doesn't have write access to them) and the content owned by a third. You then use groups to arrange for the server to have appropriate access to 'stuff' (read access to the content and configs), the server admin to have write access to the config and content management (person or system, as appropriate) write access to the content but no access to the config.
None of these UIDs should be personal accounts or root.
On Thu, Dec 07, 2017 at 12:40:27PM +0000, Huge wrote:
On Thu, 2017-12-07 at 11:45 +0000, Chris Green wrote:
On Thu, Dec 07, 2017 at 11:04:06AM +0000, steve-ALUG@hst.me.uk wrote:
On 07/12/17 11:00, Huge wrote:
On Tue, 2017-12-05 at 09:52 +0000, Chris Green wrote:
The current problem is that syncthing doesn't deal well with directories and files which have different owners on different systems.
In which case you either need to replace syncthing, or give the directories and files the same owners on different systems!
+1
If you are replicating files between systems, it does help to have the same usernames, groups, user numbers/ids and group ids, at least for users who have files on multiple machines.
Absolutely!!! That's what prompted the question, I'm *trying* to make things so that files are owned by 'chris' everywhere but the requirement to give www-data access as well makes that difficult.
You need three UIDs to safely run a web server, and none of them should be "chris". The server itself should run as one UID, its configuration files should be owned by a second (so it doesn't have write access to them) and the content owned by a third. You then use groups to arrange for the server to have appropriate access to 'stuff' (read access to the content and configs), the server admin to have write access to the config and content management (person or system, as appropriate) write access to the content but no access to the config.
A counsel of perfection but I've not seen this on a small system, ever.
In reality on most home Linux boxes you will have root as the UID that has access to the web server's configuration and www-data (or another non-user UID) that the web server runs as *and* which owns the 'stuff' files.
In fact I don't really see how the web server *can* have a different UID from the 'stuff', in many situations the web server will create files (e.g. my wiki) and files thus created will be owned by the web server UID. This is essentially my problem, if I could set things so that files created by the web server were owned by some other UID it would solve my problem.
None of these UIDs should be personal accounts or root.
On a big internet facing system I agree, however on a home system without outside access it is IMHO unnecessary. I have root owing the apache2 configuration files and apache2 running with UID www-data which also owns (most of) the web files. The exception is my wiki - which is where we came in! :-)
On Fri, 2017-12-08 at 08:50 +0000, Chris Green wrote:
On Thu, Dec 07, 2017 at 12:40:27PM +0000, Huge wrote:
On Thu, 2017-12-07 at 11:45 +0000, Chris Green wrote:
On Thu, Dec 07, 2017 at 11:04:06AM +0000, steve-ALUG@hst.me.uk wrote:
On 07/12/17 11:00, Huge wrote:
On Tue, 2017-12-05 at 09:52 +0000, Chris Green wrote:
The current problem is that syncthing doesn't deal well with directories and files which have different owners on different systems.
In which case you either need to replace syncthing, or give the directories and files the same owners on different systems!
+1
If you are replicating files between systems, it does help to have the same usernames, groups, user numbers/ids and group ids, at least for users who have files on multiple machines.
Absolutely!!! That's what prompted the question, I'm *trying* to make things so that files are owned by 'chris' everywhere but the requirement to give www-data access as well makes that difficult.
You need three UIDs to safely run a web server, and none of them should be "chris". The server itself should run as one UID, its configuration files should be owned by a second (so it doesn't have write access to them) and the content owned by a third. You then use groups to arrange for the server to have appropriate access to 'stuff' (read access to the content and configs), the server admin to have write access to the config and content management (person or system, as appropriate) write access to the content but no access to the config.
A counsel of perfection but I've not seen this on a small system, ever.
In reality on most home Linux boxes you will have root as the UID that has access to the web server's configuration and www-data (or another non-user UID) that the web server runs as *and* which owns the 'stuff' files.
In fact I don't really see how the web server *can* have a different UID from the 'stuff', in many situations the web server will create files (e.g. my wiki) and files thus created will be owned by the web server UID. This is essentially my problem, if I could set things so that files created by the web server were owned by some other UID it would solve my problem.
None of these UIDs should be personal accounts or root.
On a big internet facing system I agree, however on a home system without outside access it is IMHO unnecessary.
Why not just Do It Right?
On Sat, Dec 09, 2017 at 09:27:25AM +0000, Huge wrote:
In reality on most home Linux boxes you will have root as the UID that has access to the web server's configuration and www-data (or another non-user UID) that the web server runs as *and* which owns the 'stuff' files.
In fact I don't really see how the web server *can* have a different UID from the 'stuff', in many situations the web server will create files (e.g. my wiki) and files thus created will be owned by the web server UID. This is essentially my problem, if I could set things so that files created by the web server were owned by some other UID it would solve my problem.
None of these UIDs should be personal accounts or root.
On a big internet facing system I agree, however on a home system without outside access it is IMHO unnecessary.
Why not just Do It Right?
OK, tell me how I set things up so that files created by the web server aren't owned by the web server.
... also tell me how I make things more secure by deviating by a very large amount from the standard distribution configuration. The likelihood of there being an error (which will make security holes) in a 'one man' customisation of a standard set up is considerable.
{SOME SNIPPING}
On 09/12/17 10:21, Chris Green wrote:
On Sat, Dec 09, 2017 at 09:27:25AM +0000, Huge wrote:
Why not just Do It Right?
OK, tell me how I set things up so that files created by the web server aren't owned by the web server.
Suggestions previously offered. Also from Apache WIKI https://wiki.apache.org/httpd/FileSystemPermissions
... also tell me how I make things more secure by deviating by a very large amount from the standard distribution configuration. The likelihood of there being an error (which will make security holes) in a 'one man' customisation of a standard set up is considerable.
An analogy. Ubuntu has a default firewall, but it's not shipped in "Enabled" state. It is recommended that you configure & enable it, but they don't do it for you. You have to set up a one man customisation and it makes things more secure.
I have also done a one man customisation of: email dns ssh printing antivirus ssh monitoring networked file sharing wifi log-file analysing ad-blocking privacy-measures backups and probably many more things.
All to try and make things more secure.
It's standard practice.
Steve
On Sat, Dec 09, 2017 at 06:32:40PM +0000, steve-ALUG@hst.me.uk wrote:
{SOME SNIPPING}
On 09/12/17 10:21, Chris Green wrote:
On Sat, Dec 09, 2017 at 09:27:25AM +0000, Huge wrote:
Why not just Do It Right?
OK, tell me how I set things up so that files created by the web server aren't owned by the web server.
Suggestions previously offered. Also from Apache WIKI https://wiki.apache.org/httpd/FileSystemPermissions
Read that carefully, it *doesn't* do what you suggest.
... also tell me how I make things more secure by deviating by a very large amount from the standard distribution configuration. The likelihood of there being an error (which will make security holes) in a 'one man' customisation of a standard set up is considerable.
An analogy. Ubuntu has a default firewall, but it's not shipped in "Enabled" state. It is recommended that you configure & enable it, but they don't do it for you. You have to set up a one man customisation and it makes things more secure.
I have also done a one man customisation of: email dns ssh printing antivirus ssh monitoring networked file sharing wifi log-file analysing ad-blocking privacy-measures backups and probably many more things.
All to try and make things more secure.
I have probably done much of the above too but it *doesn't* equate to what you are suggesting one does to apache (even if it's possible which I'm beginning to doubt). Virtually all the above customisation is on one's home directory and thus doesn't prevent one having an absolutely standard installation. You could do most of the above and just save /home to put back over a clean install of a new system.
On 09/12/17 21:22, Chris Green wrote:
On Sat, Dec 09, 2017 at 06:32:40PM +0000, steve-ALUG@hst.me.uk wrote:
{SOME SNIPPING}
On 09/12/17 10:21, Chris Green wrote:
On Sat, Dec 09, 2017 at 09:27:25AM +0000, Huge wrote:
Why not just Do It Right?
OK, tell me how I set things up so that files created by the web server aren't owned by the web server.
Suggestions previously offered. Also from Apache WIKI https://wiki.apache.org/httpd/FileSystemPermissions
Read that carefully, it *doesn't* do what you suggest.
I believe the "suggestions previously offered" go some way to doing what you want. The link was merely an "also" which more-or-less confirms what "Huge" was saying.
... also tell me how I make things more secure by deviating by a very large amount from the standard distribution configuration. The likelihood of there being an error (which will make security holes) in a 'one man' customisation of a standard set up is considerable.
An analogy. Ubuntu has a default firewall, but it's not shipped in "Enabled" state. It is recommended that you configure & enable it, but they don't do it for you. You have to set up a one man customisation and it makes things more secure.
I have also done a one man customisation of: email dns ssh printing antivirus ssh monitoring networked file sharing wifi log-file analysing ad-blocking privacy-measures backups and probably many more things.
All to try and make things more secure.
I have probably done much of the above too but it *doesn't* equate to what you are suggesting one does to apache (even if it's possible which I'm beginning to doubt). Virtually all the above customisation is on one's home directory and thus doesn't prevent one having an absolutely standard installation. You could do most of the above and just save /home to put back over a clean install of a new system.
OK, my list above
email dns ssh printing antivirus ssh monitoring networked file sharing wifi log-file analysing ad-blocking privacy-measures backups
Every single one of those on my system, except wifi and backups requires some server to be installed in a bin directory, and to be configured in /etc/ or a subdirectory thereof.
you're right about wifi. One of my backup systems is configured as a particular user, but backs up everything. My other backup systems require software and servers or serices installed and are configures in /etc or subdirectories thereof.
" Virtually all the above customisation is on one's home directory and thus doesn't prevent one having an absolutely standard installation. You could do most of the above and just save /home to put back over a clean install of a new system. "
I believe for the examples I have given, that that is incorrect.
Almost everyone is going to have installed particular software that may not be installed by default, and almost certainly configured it away from the default settings (e.g. Syncthing). Apache doesn't come preconfigured to run a wiki. Given that it has already been configured to run a wiki, it seems odd to express a desire not to configure it.
Steve
On Sat, Dec 09, 2017 at 10:33:35PM +0000, steve-ALUG@hst.me.uk wrote:
On 09/12/17 21:22, Chris Green wrote:
On Sat, Dec 09, 2017 at 06:32:40PM +0000, steve-ALUG@hst.me.uk wrote:
{SOME SNIPPING}
On 09/12/17 10:21, Chris Green wrote:
On Sat, Dec 09, 2017 at 09:27:25AM +0000, Huge wrote:
Why not just Do It Right?
OK, tell me how I set things up so that files created by the web server aren't owned by the web server.
Suggestions previously offered. Also from Apache WIKI https://wiki.apache.org/httpd/FileSystemPermissions
Read that carefully, it *doesn't* do what you suggest.
I believe the "suggestions previously offered" go some way to doing what you want. The link was merely an "also" which more-or-less confirms what "Huge" was saying.
It doesn't *work*! As it says "Because the group "web-content" is applied to all the files and directories, httpd can read these files, but cannot write to them." it means that things like wikis won't work as the httpd (well apache2) processes need to be able to write to the web content areas. Surely that same applies to blogs as well if you can update them from the web.
Virtually all the above customisation is on one's home directory and thus doesn't prevent one having an absolutely standard installation. You could do most of the above and just save /home to put back over a clean install of a new system. "
I believe for the examples I have given, that that is incorrect.
It depends how you do it! :-)
My backups *are* done by root with custmisation in /etc (i.e. adding a file to /etc/cron.daily) but that's about it as regards extras in /etc.
My dns 'customisation' is in a Raspberry Pi which I suppose you could regard as 'root' but it's so small that it all fits on a 2Gb stick and hence is trivial to keep backed up.
Apart from these, partly because I *do* try very hard not to customise my system in a way that will break on upgrade/re-install, just about everything else is in /home.
On 10/12/17 09:17, Chris Green wrote:
Apart from these, partly because I *do* try very hard not to customise my system in a way that will break on upgrade/re-install, just about everything else is in /home.
I've been updating my /etc/ configured *buntu since April 2010 without it breaking.
Steve
On Mon, Dec 11, 2017 at 04:32:52PM +0000, steve-ALUG@hst.me.uk wrote:
On 10/12/17 09:17, Chris Green wrote:
Apart from these, partly because I *do* try very hard not to customise my system in a way that will break on upgrade/re-install, just about everything else is in /home.
I've been updating my /etc/ configured *buntu since April 2010 without it breaking.
and? Yes, of course you can, I just feel safer and happier the *less* non-standard I have in my system.
... and I've been doing it for a lot longer than since 2010! :-)
On Thu, Dec 07, 2017 at 11:00:28AM +0000, Huge wrote:
On Tue, 2017-12-05 at 09:52 +0000, Chris Green wrote:
The current problem is that syncthing doesn't deal well with directories and files which have different owners on different systems.
In which case you either need to replace syncthing, or give the directories and files the same owners on different systems!
Syncthing does a fantastic job for me, in general it 'just works', the alternatives I've looked at don't seem to be so good (for me anyway).
... and the files *are* owned by me ('chris') everywhere, I'm just trying to find a way to enforce that even though www-data has read/write access.
-
Chris Green -
Huge -
steve-ALUG＠hst.me.uk