(edit the /etc/group file to add the allowededitor to group allowededitors and www_data)
cd /path/to/module/files
chown file.php allowededitor
^D
login as allowededitor
cp file.php file_orig.php
edit the file.php at will
Meanwhile, the integrity check notices a change in file(s) ownership and that itās been edited, and displays a notice in dashboard.
Then module admin has a line āthis module has local changes by $allowededitorā, a checkbox to check for the admin āThe admin knowsā, which upon being checked, makes it NOT display the notice on dashboard any more, and a button ārevert to online versionā; Slightly more advanced - recognize EVERY SINGLE modified file and let them be reverted one by one [say someone wants to edit his javascripts - like, make the dashboard graphs display meaningfulā¦ without affecting the way the other php files still work vs the online version.]
Now youāve created a massive issue with our chown system in that it has to somehow know how to skip these files. This is way more overkill than just doing a root owned file that has keys and hashes in it
OK, so Iām not a developer :J didnāt even know that existed, sorry.
But, but: if the chown system could read one more file (owned by rootā¦), stating which group and/or user is allowed to own locally edited files ? and yell if it belongs to www_data?
(I realize this is hardly stable material but on more serious note, I can see where people have the problem, not being able to tinker around with the code on their own machinesā¦ whilst still staying under integrity check protection.)
It has been said many times, but it bears repeating. Nobody is being prevented from tinkering or editing files on their own system. The ENTIRE conversation in aid of preventing these tinkerers from getting FreePBX security notices that files have been modified.
Yes youāre right, and wrong at the same time
What bears repeating and seems to be not recognized because no one said that explicitly, is that people WANT to tinker with files, AND have the integrity check ACK their changes as valid (and have ample notice but just NOT in dashboardā¦), AND otherwise USE the integrity checking to recognize when somebody not-allowed, did. Hence the idea with special user/group allowed to locally edit files or actually own whole module(s)ā¦
Because, why, you may ask ?
a) my own āthingā about the timeline on dashboard to be made meaningfulā¦
b) about the locally-installed modules which have been the root of all evil :j in previous thread.
c) pipe dream maybe, but those who do know what they are doing, could EASIER rollup and send you patchesā¦ while not making an impression of running a compromised system.
Iām killing this āspecialā user/group thing right now. Good idea in premise. But you yourself said you arenāt a developer, so you donāt understand how framework works and why this is such a bad idea. You canāt work with FreePBX and expect framework to be OK with you locking out files from the web services updating it. What if we added new methods to classes that other items expect. It happens more than you think. If you locked out that file that NEEDS to be updated and went through the Framework upgrade process and all files around that file were updated then bam you have a dead system. How are you going to get out of it? You canāt, unless you go download that one single file manually, not through the GUI (its broken) and not through the CLI (also broken). Your idea, in theory, is great. It will not work in FreePBX
Even for noticing this idea, thank you ā¦ and for your kind words.
(and Iām not actually going to continue this in the other looong thread)
If, however the prerequisites to all that were set in stone say, IF one wants to change a file, MUST understand the whole module is going to be locked, AND will prevent other modules depending on that one from updating ? That in itself creates ample alarms already.
Note there are many ānot developersā who are now developers because they had a task they wanted to solve. You may find this it the task that flips you to the dark side.
We have quite a few contributions from ānot developersā. Many had an idea that there were no official resources for. They took that idea, used #freepbx-dev on irc and our wiki to turn out what they wanted. Contrary to popular commentary all of the internal developers are super nice and happy to be helpful.
Unfortunately due to time zones I canāt currently check whether e.g.
editing the status page graphs would break frameworkā¦
If not for that, the feature would at least allow to inconspicuously run
things like possa modules. And still keep an eye on them, while not
requiring anyone to sign anything.
Just saying.
Kind regards to all who read this.
but on more serious note, I can see where people have the problem, not being able to tinker around with the code on their own machinesā¦ whilst still staying under integrity check protection.)