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

Logs lose permissions after rotation #21

Closed
tomalok opened this issue Nov 29, 2020 · 8 comments · Fixed by #22
Closed

Logs lose permissions after rotation #21

tomalok opened this issue Nov 29, 2020 · 8 comments · Fixed by #22

Comments

@tomalok
Copy link
Contributor

tomalok commented Nov 29, 2020

alpine@m0:~$ ls -l /var/log/docker.log*
-rw-------    1 root     root       4958249 Nov 29 04:35 /var/log/docker.log
-rw-r--r--    1 root     docker    10485892 Nov 20 20:44 /var/log/docker.log.20201120204416
-rw-------    1 root     root      10823084 Nov 29 02:42 /var/log/docker.log.20201129024242

The init.d script sets the initial mode & ownership, but that's not persisted going forward.

It would be nice if either...

  • log_proxy would preserve the original mode/ownership
    ...or...
  • log_proxy could be provided options to set mode/ownership
@thefab
Copy link
Member

thefab commented Nov 29, 2020

it makes perfectly sense! let's fix that!

@thefab
Copy link
Member

thefab commented Nov 30, 2020

note: the option to change ownership can work only for the root user

@thefab
Copy link
Member

thefab commented Nov 30, 2020

I have an implementation with this new option:

  -c, --chmod               if set, chmod the logfile to this octal value (0700 for example)

@tomalok it would be ok for you?

@tomalok
Copy link
Contributor Author

tomalok commented Dec 1, 2020

While an explicit --chmod is welcome, it doesn't address/solve the ownership issue (in my case, root:docker; FWIW, I haven't take a close look at the PR yet so I don't know offhand if a solution is in there).

I think an implicit solution might be a little easier to do... That is, when logs are rotated, log_proxy would stat the old log file and then TRY to chmod and chown the new log file to be the same. If the user that log_proxy is running as does not have sufficient privileges to set either the mode or the ownership (i.e. the chmod or chown fails) that's okay, and move along (maybe emit a warning somewhere).

@thefab
Copy link
Member

thefab commented Dec 1, 2020

Yes, the PR is only a beginning about permissions.

I don't like the implicit solution because the final result depends on original state. IMHO, it would be perfectly ok for a stateful thing like a database. But here with logs, I don't like the fact that if you clean your log directory (which sounds ok at any time), you will get some different results about permissions and ownership.

So i'm going to introduce a "best effort" explicit chown option.

@thefab
Copy link
Member

thefab commented Dec 1, 2020

new options introduced in the PR:

+    { "chmod", 'c', 0, G_OPTION_ARG_STRING, &chmod_str, "if set, chmod the logfile to this octal value (0700 for example)", NULL },
+    { "chown", 'o', 0, G_OPTION_ARG_STRING, &chown_str, "if set, try (if you don't have sufficient privileges, it will fail silently) to change the owner of the logfile to the given user value", NULL },
+    { "chgrp", 'g', 0, G_OPTION_ARG_STRING, &chgrp_str, "if set, try (if you don't have sufficient privileges, it will fail silently) to change the group of the logfile to the given group value", NULL }

@tomalok: ok for your use-case ?

@tomalok
Copy link
Contributor Author

tomalok commented Dec 4, 2020

@thefab that should do the trick for me.

@mergify mergify bot closed this as completed in #22 Dec 5, 2020
mergify bot pushed a commit that referenced this issue Dec 5, 2020
@thefab
Copy link
Member

thefab commented Dec 7, 2020

@tomalok 0.4 is out ;-)

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

Successfully merging a pull request may close this issue.

2 participants