You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Because this runs on init even if macaron is not going to be started, if it is linked to a binary it will prevent the binary from starting if it is started in a non-readable working directory.
A workaround is possible but it's not ideal. Is there any way to avoid panicking here?
The text was updated successfully, but these errors were encountered:
If any part of a binary imports macaron then macaron's init will run. So if you have subcommands in your binary, even if that subcommand doesn't need macaron the macaron init will run and will cause a panic.
It may be that we should be separating out our subcommands from the main binary, but in any case panicking in an init is a fairly harsh thing to do. You can't reasonably manage such a situation or provide appropriate logging to the user.
(I could imagine a situation whereby you might want to run in a non-readable working directory but have macaron have its own configuration. That way if there is a security exploit and people are able run a command from your application they will find it very difficult to run anything because their working directory will be unreadable.)
Hi!
The init method for macaron causes a panic if the current working directory cannot be read.
macaron/macaron.go
Line 315 in 4df59ae
Because this runs on init even if macaron is not going to be started, if it is linked to a binary it will prevent the binary from starting if it is started in a non-readable working directory.
A workaround is possible but it's not ideal. Is there any way to avoid panicking here?
The text was updated successfully, but these errors were encountered: