-
Notifications
You must be signed in to change notification settings - Fork 285
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
Macaron causes panic on starting gogs/gitea in an unwritable/unreadable directory #175
Comments
Thanks for the feedback! If working directory is not readable, what's the point of starting the binary? |
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.) |
OK, it makes sense. It indeed kind of annoying. |
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: