RFC: recognize locally edited modules by ALLOWED real system user as valid?

Continuing the discussion from Any way to disable module signature checking for an individual module?:

So the proposed workflow to that would be:
(in pseudocode and pseudoshell)

(as root)
adduser allowededitor
addgrp allowededitors

(edit the /etc/group file to add the allowededitor to group allowededitors and www_data)

cd /path/to/module/files
chown file.php allowededitor

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 :wink: 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.

Not to mention the fact that this would break Web updates.

Yes you’re right, and wrong at the same time :slight_smile:
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.

That would work for every module except framework.

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.

Thanks to all developers who patiently read this.

Also thanks for the ‘patches welcome’ hint :wink:

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.

Here’s the route we are going to go:


Can’t wait already :wink:

1 Like