1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Not Planned Prevent direct add-on access to the database

Discussion in 'Closed Suggestions' started by psTubble27, Jul 29, 2013.

  1. psTubble27

    psTubble27 Well-Known Member

    Add-ons create sql tables they need for their usage. When they are uninstalled however, there can remain orphan sql tables.

    Instead all database access should filter through the XF engine. The addon would invoke a function like xen_create_table("tablename"). This would allow XF to keep track of all add-on created tables, and when uninstalled, to clean up those tables automatically.

    In the ideal world, uninstalling 100 add-ons would leave the database in the same pristine state as if they were never installed.

    The primary benefit of this feature is that if the add-on is unneeded, or presents a security risk, its data can be gotten rid of without technical hassle.
  2. Jeremy

    Jeremy Well-Known Member

    If an add-on doesn't uninstall tables and or removed added columns, you should report it to the developer. It's up to the add-on author to properly install / uninstall their add-on. And nothing XenForo does can prevent the situation you describe, if an add-on wants to access the database, XenForo can't prevent that or force them to use their classes.
  3. Brogan

    Brogan XenForo Moderator Staff Member

    Agree with KK on all points.
  4. JulianD

    JulianD Well-Known Member

    However, the idea of an install/uninstall framework for addons is not bad at all.
  5. tyteen4a03

    tyteen4a03 Well-Known Member

    The system will need to help devs make upgrading easier.

    OT: It's not XenForo's problem an addon developer is not cleaning up their own mess.
    0xym0r0n and Bob like this.
  6. Jeremy

    Jeremy Well-Known Member

    The benefits it will give developers is minimal.
  7. psTubble27

    psTubble27 Well-Known Member

    In broad terms this is a Xenforo ecosystem. We rely on XF to keep things in order, if the add-on developer is incompetent and/or malicious. If there is a virus in a Windows environment nobody says "hold the virus author accountable, why do you blame Microsoft". No we involve Microsoft as well, because it's their ecosystem.

    Now it's another thing entirely, if XF just physically cannot prevent add-ons from accessing the database, but the utility of the principle in the abstract can't be denied.
  8. Jeremy

    Jeremy Well-Known Member

    Comparing Microsoft to XenForo is like comparing Earth to a house. When on Microsoft, I would have to use functionality exposed to me for it to work. If I really wanted to, I could write my add-on without using XenForo's database classes at all, because all of the direct PHP functions are available.

    As I said a few minutes ago, the actual benefit it gives developers will be extremely small, if any at all. The queries that are used to create a table are slightly more complex than "Create Table X".

    Also, having data in the database can't really pose a security risk after an add-on is uninstalled.
  9. Marcus

    Marcus Well-Known Member

    The code of xenForo is based on the framework from ZEND. Some frameworks work like psTubble27 suggested. ZEND does not work like this, here you access the database directly with SQL queries. Bottom line: As long as ZEND does not include this (which it most likely does not), this suggestion can't be (or it is too much hassle to do so) implemented.
  10. tyteen4a03

    tyteen4a03 Well-Known Member

    The term you're looking for is Object Relations Manager (ORM).

    And no, there isn't an ORM in either ZF1 or 2. However, XF can implement anything they need without relying on Zend - XenForo is not a strict ZF-based app.
    psTubble27 and Marcus like this.
  11. psTubble27

    psTubble27 Well-Known Member

    I think you are missing the point of this suggestion. The point here is not to provide a benefit to developers but to provide a benefit to consumers, which may make things more difficult for developers than anything else.

    Isn't that just up to XenForo's architecture? It isn't possible for an add-on to run without it running within XF. If XF architecture will prohibit the addons from having this access, you wouldn't be able to.

    It may if there's data in your own database you didn't want to store and which some other add-on later can retrieve. Also it is a matter of space and efficiency. I don't see why you are trying to shoot this down so hard.
  12. Mike

    Mike XenForo Developer Staff Member

    I'm getting confused as I feel like you're proposing from two different things and I don't know what you're actually suggesting.

    The initial suggestion is roughly something that only benefits developers directly, in that it automatically cleans up data for them. Obviously they should be cleaning up their data on uninstallation and this could make it happen automatically, but there's nothing to stop them from doing it now. It just prevents them from having to write the code explicitly. (Conversely, there are things they may still need to clean up manually anyway.)

    But then this seems to have taken a turn into sandboxing to provide security by limiting add-on access to APIs. Let's just say this is simply not possible. Comparisons to operating systems (or even any binary-based executable) are really of no use because they're simply not relevant to this situation.
    tyteen4a03 and Marcus like this.
  13. Jeremy

    Jeremy Well-Known Member

    As Mike said, it seems you've switched the reason for this like Mike said. But either way, my comment still stands. There is nothing stopping me from writing my own SQL queries and interacting with the database directly. And data doesn't pose a security threat, but it now seems to me that you are more worried about limiting access to such data for other add-ons (impossible) or worried about space, which your suggestion can't really achieve.

    As Mike has said, just table creations aren't necessarily all the clean up that needs to happen and there is no way XenForo can provide sandboxed APIs for every single possible method of storing something (uploads, tables, columns, etc.), so its more or less up to the developer to properly clean up anyways.
  14. psTubble27

    psTubble27 Well-Known Member

    Sorry, I see how what I said could could've been unclear. I did mention the developer-friendly database function, but the point of having it was, so as to funnel all DB access through XF, preventing add-ons from having direct access. Hence the title of the thread.

    I am proposing a system that will give developers less access to the system. If we funnel everything through XF core (and give it a friendly face so that the devs won't grumble), then XF can keep tabs on everything add-ons do. If the add-on uninstalls, we can clean up all the mess after it.

    The system could be applied in very powerful ways in future years. For example it could monitor add-on activities and even prevent malicious behavior from taking effect. Something robust like that, protecting users, has not been seen in forums to date which makes it a perfect target for XF innovation.
  15. Jeremy

    Jeremy Well-Known Member

    You want sandboxing. This is impossible with a web application. No matter how 'friendly' the XenForo functions are, anybody could write a script that includes the XenForo configuration, get the database details, and connect directly to the database.
  16. psTubble27

    psTubble27 Well-Known Member

    I look at the countless add-ons that are now sprouting up in the Resources section, and I can't help but think that they are NOT viable for a quick download and experiment. Forum and DB integrity have paramount importance to a careful administrator, and add-ons having unlimited rights means that he has to trust the add-on authors with the life of his forum, or even better, be expert in PHP and go through their source code himself. Most people won't be. Anything less than this knowledge will mean that the security concerns override the download-and-experiment impulse, among a large chunk of the XF userbase. Only the incompetent admin will experiment with ALL add-ons, and the virtuoso PHP admin will just code everything himself (like digitalpoint did).

    If add-ons were in a sandbox (perhaps in just one aspect for now, such as DB access, and expand in their control in future releases), this would lead to a lot more downloading and experimentation with add-ons, without fear that they would sully the database with garbage tables, and at worst corrupt the system through incompetence.

    You are assuming a security breach. How would a regular person get the configuration/DB details without hacking?
    Last edited: Jul 30, 2013
  17. Mike

    Mike XenForo Developer Staff Member

    There is always a database object that can access things. Anything that XF can read can be read by an add-on.

    What you are asking for is simply not possible (from a security standpoint).
    psTubble27 likes this.
  18. psTubble27

    psTubble27 Well-Known Member

    Ahh I see. Thanks for responding Mike.

    I come from a desktop dev. environment and especially the Java sandbox model. Could somebody explain in specifics why it isn't possible? If I just approach it analytically, the XF php file (say, index.php) is always loaded first when you enter the XF system at any point, so theoretically the XF core should always be in control if it wanted to...

    Also, if this database object can be read by any add-on, am I correct in assuming that it is one huge security breach waiting to happen (again, coming from the JVM and the PC protected memory world)? Can an add-on basically retrieve all database config settings for your site? I understand that it's not a XF-specific issue. Just trying to get a handle on how far this problem extends.
  19. Jeremy

    Jeremy Well-Known Member

    No, any add-on can include the XF configuration and access the DB. As Mike said, this is impossible from a technical stand point. Sandboxing would need implemented in PHP.

    PHP has access to the DB natively.
    tyteen4a03 and psTubble27 like this.
  20. Biker

    Biker Well-Known Member

    Of course, we all know how secure that model is. Hasn't been a java exploit in years. Oh. Wait.....

Share This Page