A user can outputlookup and overwrite existing lookups regardless of permissions

[raziasaduddin]

We just tested in 5.0.2.2 - A user did outputlookup and overwrote a lookup file in etc/system even though in the UI, users only have read access to the table definition and file. This is unacceptable. To be clear, the files have "no owner" in the splunk UI since they were just created via editing transforms.conf and the lookup csv files themselves in the command line. We are running on Windows.

How can I stop this from happening?

[dsrvern]

What an incredibly poorly designed "feature". Giving the user the option to set "Permissions", including Read and/or Write, but providing no indication whatsoever that the change does absolutely nothing to restrict permissions. Who thought this was a good idea?

[fernandoandre · Accepted solution]

All our splunk instances are on versions 6.5+ and we run into the exactly same problem.
We investigated and developed/tested 2 possible workarounds, however only one worked. This was our solution to the problem.

According to the command outputlookup documentation here
“For permissions in CSV lookups, use the “check_permission” field in transforms.conf and “outputlookup_check_permission” in limits.conf to restrict write access to users with the appropriate permissions when using the outputlookup command. Both check_permission and outputlookup_check_permission default to false. Set to true for Splunk software to verify permission settings for lookups for users.”

So in addition to our existing default.meta file we also added the following:
transforms.conf

[default]
check_permission = true

[mylookuptable]
filename = yourLookupName.csv
check_permission = true

limits.conf

[outputlookup]
outputlookup_check_permission = true

On transforms.conf it’s possible to either go with the [default] stanza approach or be more specific, according to each specific situation.

It’s worth mentioning that this will prevent the lookups from being written by the outputlookup command, however it will show a not very friendly message. Example below:

“Error in outputlookup command: User YOURUSER with roles [YOURROLE(s)] cannot write /nobody/YOUR_APP_NAME/lookups/yourLookupName.csv {list of actual permissions you have defined in your default.meta”

Hope it helps.

[the_wolverine]

Confirmed that this works. Thank you.

Had a case open with Splunk for several years and no update. Disappointing.

[martin_mueller]

This is controllable via the output_file capability. By default, the user role already has the capability enabled.

http://docs.splunk.com/Documentation/Splunk/6.3.3/Admin/authorizeconf

[awmorris]

I realize this is an old thread but I'm going to respond because it still remains an issue with Splunk 6.4.0. the_wolverine is right that outputlookup doesn't respect the permission setting. This is not proper behavior for least three reasons.

ONE:
It doesn’t pass the intuitive test. Part of the appeal of Splunk is that the product is so intuitive. If I navigate to an object and revoke write permissions through the check box, I intuitively expect that a box without no checkmark means the role is unable to write.

TWO:
Checking/unchecking the permissions 'write' box has ZERO effect on the behavior. It is simply not logical to say that the system is operating as designed when changing permissions has no effect on the outcome.

THREE:
Revoking the outfile_file capability is an all or nothing deal. We have a specific requirement that security analysts may overwrite/alter certain lookups (e.g. malicious IP addresses) but restrict them from altering other lookups (e.g. Human Resource information). The capabilities as shown in the GUI reflect the way the product should in fact be designed. However, as the product operates, ANYONE with output_file capability can overwrite/alter the output file of ANY other user.

Not sure what happened to the_wolverine's ticket but I also opened a ticket also to see if we can have someone at Splunk revisit this behavior.

[dflodstrom]

bump. We applied this fix ages ago but still seems to be an issue today.

[martin_mueller]

I get that, but that's not what knowledge object permissions do. Those control if you can edit the knowledge object, ie the .conf entry.

Getting RBAC for writing to .csv files, whether they're defined as a lookup or not, is an interesting enhancement to request though.

[the_wolverine]

Then there should not be READ/WRITE settings capability for individual lookups. That's just lying. Anyway, RFE filed.

[martin_mueller]

I wouldn't say "lying", I'd say "different purpose". It'd be "lying" if the docs claimed that KO permissions influenced the output_file capability.

[the_wolverine]

Issue is that user should not be able to overwrite an existing lookup which he does not have write capability to edit. Outputlookup doesn't respect the permission setting.

[ben_leung]

Example, if I do index=main | stats count by sourcetype | outputlookup ben_test.csv, the file should not be overwritten if another user runs ... |outputlookup ben_test.csv

[raziasaduddin]

Yes I did.

[ben_leung]

This is still the case in version 6.3.3. Does this mean that this behavior is expected from Splunk and that it will not change? Do other customers face this challenge of overwriting existing lookups? Or do they want to overwrite the lookup files purposely?

[the_wolverine]

Did you receive a resolution on this? Sounds like basic permissions bug if still doing this.

[lguinn2]

Did you file a support ticket?