Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add getLoggers method and save name of loggers on instance #114

Merged
merged 3 commits into from
Nov 13, 2017

Conversation

iabw
Copy link

@iabw iabw commented Nov 2, 2017

Hi! Tidy little lib, but I wanted to be able to generate a list of all my loggers so the user can select the level for each logger themselves. This was all I needed to do that.

@pimterry pimterry merged commit 8ac6bf6 into pimterry:master Nov 13, 2017
@pimterry
Copy link
Owner

Looks great, merged. Thanks!

@iabw
Copy link
Author

iabw commented Nov 14, 2017

Thanks @pimterry - I thought I had left a comment about this, but apparently I never submitted it -

Is this 'getAllLevels' method a potential opsec problem? It allows access to a private variable that previously was inaccessible, right? You used to have to know how to get the logger you wanted (or already have a reference to it). With this change, a third party could modify messages in an app that the app author didn't intend to allow modifying.

It's an edge case, but worth considering.

@pimterry
Copy link
Owner

@iabw that was already possible - that code could just register a plugin, which would get called any time any logger was registered and given its name.

In general, loglevel doesn't provide any privacy within the same JS process, and I'm not sure any standalone JS library really can at all without reimplementing an entire JS runtime. That's not really an existing feature of the language. By the time you've got untrusted code running inside your javascript process, everything else in that process is effectively public, since there's no real true isolation or inaccessibility mechanisms in JS. Untrusted JS could read the source of the whole app and parse out all the logger names by hand to do this, for example, or even transform and then rerun loglevel's initialization code to make private vars public for itself.

Even the VM module in node, which runs code in a whole new V8 virtual machine has a big warning says:

Note: The vm module is not a security mechanism. Do not use it to run untrusted code.

There are specialized isolation mechanisms that try to do this kind of thing, like Jailed and Google Caja (though I've never tried either), and the problem as a whole is the subject of some interesting academic research: https://seclab.stanford.edu/websec/jsPapers/csf09-camera-ready.pdf.

I've never seriously looked into it myself, but you're definitely not going to get any serious isolation from almost any random JS library - if you truly want to run untrusted JS, it's going to be a major piece of separate isolation development that will significantly change the architecture of your code, or it's going to be broken. I'd recommend just not doing it 😃.

@iabw
Copy link
Author

iabw commented Nov 14, 2017

That's totally fair, I guess I meant more of either a footgun or "unlocked doors" vs "break in through the window". You've obviously put a lot of thought into this, so if you're cool with the getter, I'm happy to use it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants