Succinct: Someone missed to explicitly set the permissions in /etc/logrotate.d/tor. Sorry if I missed reasons not to do so. AFAIK the tor installation runs under the additional "tor" UID per default. There is a problem, as i override the default creation perm-user-group values in /etc/logrotate.conf, to something other then the tor uid. It would be good to set the tor.log permission explicitly, in /etc/logrotate.d/tor, otherwise tor doesn't start because it can't read tor.log - possibly. Adding the following in /etc/logrotate.d/tor solves it: create 600 tor tor
Created attachment 130152 [details] The /etc/logrotate.d/tor file with the line from the initial report
(In reply to comment #0) > There is a problem, as i override the default creation perm-user-group values > in /etc/logrotate.conf, to something other then the tor uid. What exactly are you overriding? No such problem here.
(In reply to comment #2) If a file gets rotated, the original logfile is packed and if necessary moved. Per default logrotate creates the now missing logfile with the same permissions, uid/gid as it had before. You can adjust all the files the way you like it and let logotate recreate them accordingly. Alternatively you can enforce a special policy by saying: "All the files which don't have an explicit specification should get <these> perm-uid-gid", so you don't miss one accidently. You do that by giving a global 'create' directive, within your main logrotate.conf file, outside any curly-block { ... }. So for example, if you want only root to modify log-files, but let members of a 'audit' group read them you can specify: create 640 root audit Actually, like that, you apply global defaults generally, for all keywords. This policy does not work, if you run an application as non-root, because they could not read the log after rotating it. For these apps you have to override this setting with a create directive especially for the corresponding logfile. Allegedly, one can restore the default by omitting any of the field in the create directive, which does not work with my version, at least not if i give the create keyword unmated. Recap: the crucial point is to give a global 'create'-default outside any curly block {} and let the tor.log rotate. Then you'll see.
Yeah, and why are you needlessly creating problems for yourself? :) This will break anything that relies on specific log permissions and installs a logrotate entry, including portage's elog feature - not just tor. Just that noone is affected until they break it for themselves.
AAAAAAAAAAH. THIS IS A %&$§%$ DEFAULT ENTRY FOR EVERYTHING THAT RUNS AS A DIFFERENT USER AND LOGS, JUST IN CASE. Just take a look in /etc/logrotate.d/* . mysql, privoxy, elog-save-summary. Consider it or drop it. I give up on this one.
