search

pimterry / loglevel

:ledger: Minimal lightweight logging for JavaScript, adding reliable log level methods to wrap any available console.log methods
MIT License
2.62k stars 157 forks source link

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

Closed iabw closed 7 years ago

iabw commented 7 years ago

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 commented 7 years ago

Looks great, merged. Thanks!

iabw commented 7 years ago

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 commented 7 years ago

@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 :smiley:.

iabw commented 7 years ago

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.