9 Replies Latest reply on Dec 7, 2017 7:46 PM by lp0055120

    bb-manifest.xml - playing nicely

    malcolm.murray

      For a long time many building block developers (including those employed by Blackboard) have added a permission entry like this:

      <permission type="java.io.FilePermission" name="&amp;lt;&amp;lt;ALL FILES&amp;gt;&amp;gt;" actions="read,write,delete"/>

      Now this is the sort of entry that (rightly) is likely to incur the "wrath of Volker" for demanding more permissions than it really needs.

       

      I'd like to know what the correct permission entries are to grant permission to areas such as

      the standard logging folder,

      the config folder for a b2 (part of me thinks that that is granted automatically but I must admit I haven't tested that)

      the folder associated with content items, that old favourite the programmers playground (PPG folder) etc.

       

      I have heard rumours of some variables that define these - e.g.:

      <permission type="java.io.FilePermission" name="BB_CONFIG/-" actions="read" />

      but it would be nice to see these <optimism>all documented nicely</optimism>

       

      Thanks,

       

      Malcolm

        • Re: bb-manifest.xml - playing nicely
          scott.hurrey

          Message received, Sir. Bb-manifest documentation is long overdue. I don't have an ETA, but I have started working on a document for the bb-manifest, as well as using modules.xml for extension points as the new preferred method.

           

          We do have the validator that you can look at, but we definitely need something easier to read.

           

          Specifically to this question, the B2 should have access to its own folder without any additional requirements. If it is asking for it, that is a bug.

           

          As for other dynamically replaced entries, here are a couple of examples showing the two that I'm aware of:

           

          <permission type="java.io.FilePermission" name="BB_HOME/logs/-" actions="read,write" />
          <permission type="java.io.FilePermission" name="BB_CONTENT/-" actions="write"/>
          3 of 3 people found this helpful
          • Re: bb-manifest.xml - playing nicely
            shane

            Hi Malcom,

             

            While I agree that it would be nice to know some of the template paths, I am a little confused by this.

             

            I haven't needed to add the <<ALL FILES>> permission to my building blocks in a long time (except where I literally needed access to all files, or I wanted to make a path configurable).Do you have an example of an operation that fails without this permission? To me it sounds a little bit like an issue that'd be caused by including the Bb JARs in the your package, as the classes loaded from your package would be restricted by the permissions of the b2.

             

            Cheers,

            Shane.

              • Re: bb-manifest.xml - playing nicely
                malcolm.murray

                Shane,

                 

                I'll check this out and get back to you. I think that in the past I had trouble with tools that wrote data to the PPG folder in a course, or the custom folder associated with a content item and this was a "quick Kronerism" that got my code working and let me move on to other pressing issues.

                 

                Malcolm.

              • Re: bb-manifest.xml - playing nicely
                mkauffman

                Now we can state that the following entry has officially incurred the wrath of Blackboard Product Development.

                <permission type="java.io.FilePermission" name="&amp;lt;&amp;lt;ALL FILES&amp;gt;&amp;gt;" actions="read,write,delete"/>

                Blackboard will be asking all B2 developers to remove that permission from bb-manifest.xml by Q4 2017. We'll be communicating this out here on our Community site, and via our Partner Newsletter. I'm posting the news here first as this discussion is quite well-read. Below is a set of permissions that one of our consultants shared which opens up everything in the Blackboard directories. These are almost as 'bad' as <<ALL FILES>> in that they let you overwrite other Blackboard files and content, for example anything in the vi directory, but are far better than allowing changes to any file in the file system.

                 

                <permission type="java.io.FilePermission" name="BB_HOME" actions="read,write,delete"/>

                <permission type="java.io.FilePermission" name="BB_CONTENT" actions="read,write,delete"/>

                <permission type="java.io.FilePermission" name="BB_HOME\logs-" actions="read,write,delete"/>

                <permission type="java.io.FilePermission" name="BB_HOME\\apps-" actions="read,write,delete"/>

                <permission type="java.io.FilePermission" name="BB_CONTENT/vi/-" actions="read,write,delete"/>

                3 of 3 people found this helpful
                  • Re: bb-manifest.xml - playing nicely
                    shane

                    Hi Mark Kauffman,

                     

                    It is good news that Blackboard Product Development is tightening the screws on security like this. I've long regarded this permission as a "code smell".

                     

                    Having said that, I am concerned that the <<ALL FILES>> permission is going to be blocked. There are some scenarios where this has been necessary. Specifically, there have been a couple of extensions I've developed which allows the configuration of a path within the Building Block. One example is Bond's Class Groups tool which allows the user to configure the path from which it picks up it's feed files. This path will obviously be different for every institution, so without this option, each institution would have to compile their own custom version of the B2.

                     

                    Cheers,

                    Shane.

                    • Re: bb-manifest.xml - playing nicely
                      malcolm.murray

                      Mark,

                       

                      Thanks, that is helpful.
                      I think what the article needs to be broadly useful though, is an indication of scenarios that would require these permissions - i.e. more complete documentation.

                       

                       

                      Some may be relatively self-explanatory (e.g. the logs area) but others are a lot more cryptic. E.g. if I want to write to the custom folder associated with a course content object which of these permissions do I need?

                       

                      Thanks,

                       

                      Malcolm.