5 Replies Latest reply on Feb 22, 2018 7:53 AM by phoffmann

    Query File Permissions

    mfair005 Rookie

      Is there a way to set up a query to show permissions for a specific file?

        • 1. Re: Query File Permissions
          Julian Wigman ITSMMVPGroup

          I’m struggling to see what this query has to do with ServiceDesk; can you expand please on what you are trying to achieve?

           

          Julian

          MarXtar Ltd

          • 2. Re: Query File Permissions
            mfair005 Rookie

            Moving to Endpoint Manager

            • 3. Re: Query File Permissions
              phoffmann SupportEmployee

              Yeah - this is more an EPM thing than a Service Desk thing

               

              So - we do *NOT* collect file permissions by default (quite a lot of DB bloat for very little win). However, this can be picked up as part of custom data in one of several ways.

               

              Fairly simple to do in principle. Some stuff depends on context, as in "what are you REALLY after / how much data / how many files are we talking?" ... as details can be quite KEY here.

               

              You've got a few possibilities. Here's what comes to mind at present (I am still waking up, so ... not exactly 100% here) .

               

              • You can write a custom vulnerability -- How To: Create a Custom Vulnerability Definition in Patch and Compliance Manager
                Even though these are primarily meant for patching stuff, the freedom of the tool allows you to (ab-)use it for darn near anything. I've been (ab-)using it as a convenient "complex reporting tool" for years now.

                This is a good option if you're looking for a small ish number of files that you care about. Say you care about 5 files ... then that'd be either 5 rules for the same custom "vulnerability" or 5 separate ustom "vulnerabilities" ... and all perfectly doable / scriptable / with return data that you can report on easily enough.

              • Option 2 would be custom data. This would be in principle a good approach if you're looking to do this for LOTS of files.

                However, this being FILES, I would argue that you'd strongly benefit from a 1:* (one-to-many) data approach, so that a single table can hold all manner of entries.

                This does come with a gotcha ... in that you need to have custom / modelled DB tables. This is a more complex process (which I *am* in the process of documenting and hope to have a magnum opus type "nose to tail" white paper with examples & so on finished around Q2/Q3 time). If you can wait, feel free to use "option 1" to begin with, and look at modelling tables for the longer term.

                1:* data looks like this ((just so you know what I'm talking about) in the inventory scan files... :

              (...)

              Motherboard - System Slot - (Number:0) - Designation =ExpressCard Slot 1

              Motherboard - System Slot - (Number:0) - Type =PCI Express

              Motherboard - System Slot - (Number:0) - Width =Unknown

              Motherboard - System Slot - (Number:0) - Usage =Available

              Motherboard - System Slot - (Number:0) - Length =Other

              Motherboard - System Slot - (Number:1) - Designation =CardBus Slot 1

              Motherboard - System Slot - (Number:1) - Type =PCMCIA

              Motherboard - System Slot - (Number:1) - Width =32 bit

              Motherboard - System Slot - (Number:1) - Usage =Available

              Motherboard - System Slot - (Number:1) - Length =Other

               

              (...)

              Again though - the latter does require custom data modelling ... which is not something that is openly documented (yet - something I intend to change this year for a bunch of reasons), so not something that I can just say "go forth and do it" sensibly (unless you're happy to wait for a few months).

               

              Depending on how badly you need this, you could use Option 1 as a "quick fix" / crutch 'til you can implement a Option 2 for the more "long term sustainable" approach (once I've published the aforementioned white paper)?

              • 4. Re: Query File Permissions
                mfair005 Rookie

                Specifically, I am looking for a query for programdata folder to show if domain users have permission to read or write

                • 5. Re: Query File Permissions
                  phoffmann SupportEmployee

                  So in that case, I'd definitely do it as a Custom Definition.

                   

                  That way, you can just script the relevant commands & control the data return (the "REASON" field), so that you can - say - have stuff like:

                   

                  REASON: "Bob from Accounting" & "Jane from Marketing" have rights to "stuff you care about".

                   

                  ... or so.

                   

                  That'd be the simplest & most useful way to approach this one. And just having it as a custom vulnerability means that your devices should scan for it quickly indeed (esp. if you've already enabled the scanning for custom defs).

                   

                  And with the custom vul, you can use anything from Powershell, to batch, to ... "preferred scripting language of choice" really.