User access to /var/log/messages

Hey all-

I’d like to be able to regularly access /var/log/messages for use within Conky. While it is possible to do this by changing the privileges associated with /var/log/messages, this goes away every few days after a log rotation. While it would be possible to sudo Conky and gain access, I’d rather not start solving all my problems with the “big hammer”. How can I change the privileges for this file so that it does not resort back to root only access every few days? Thanks .Bye.

This is set directly in /etc/logrotate.d/syslog

/var/log/warn /var/log/messages /var/log/allmessages /var/log/localmessages /var/log/firewall /var/log/acpid /var/log/NetworkManager {
    ...
create 640 root root

so the only way to change it is to edit this file (or not use logrotate at all …), but keep in mind that this change will be overwritten on logrotate update. Have you tried to open bug report requesting log permissions to be more configurable?

Hi
Look at the file /etc/permissions.local it has some information :wink:


Cheers Malcolm °¿° (Linux Counter #276890)
openSUSE 12.2 (x86_64) Kernel 3.4.6-2.10-desktop
up 2 days 7:42, 3 users, load average: 0.05, 0.11, 0.16
CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU

Negative, I haven’t posted a bug report on this…I’d been hoping that there was a simple fix that I’d missed.
If I can figure out what the log rotate schedule is, I could also cron job a fix that would change permissions back to user readable on that schedule.

Are you using conkyconf? (Easy configuring conky with conkyconf)

One could do this with lua . I just tested it and it would work … but you’ll have to run some sudo command before running conky so that sudo would remember your password or you would have to be member of the wheel group without password.

Right now conky_parselog re-parse the ${tail} conky variable, which just follows the file system access rights. One could replace this command with ‘sudo tail’. See the code below:

-- parse log files
function conky_parselog (...)
	local logfile,n,color,noparse
	if (arg[1]) then logfile = arg[1] else return "" end
	if (arg[2]) then n = tonumber(arg[2]) else n = 3 end
	if (arg[3]) then color = arg[3] else color = 'ff0000' end
	if (arg[4]) then noparse = arg[4] else noparse = 1 end
	if n > 30 then n = 30 end
--	local log = str2table(conky_parse('${tail ' .. logfile .. ' ' .. n .. '}')) 
	local l = assert(io.popen("sudo tail -" .. n .. " " .. logfile))
	log = {}
 	for s in l:lines() do table.insert(log, s) end
	l:close()
	local i = table.getn(log)
	local s = 0
	if i > n then 
		s = i - n
	end
	local lines, line = ""
	while i > s do
		line=log*
		line = line:gsub("%$", "%%$$")
		line = line:gsub("%+", "%%+")
		line = line:gsub("%*", "%%*")
		if noparse == 1 then
			line=line:gsub('%w*  *%w*  *(%d:]*)  *%w*  *(%w.-_*)(:*) * %d.]*]', "${color aaaaaa}%1 ${color white}%2%3", 1)
			line=line:gsub(logfile:gsub('/.*/(%w*).*',"%1: ",1),"",1)
			line=line:gsub(': ',": ${color " .. color .."}",1)
			line=line:gsub('#',"\\#")
			line=line:gsub('%w*  *%w*  *(%d:]*)  *%w*  *(%w.-_*): *', "${color aaaaaa}%1 ${color white}%2: ${color " .. color .."}",1) 
		else
			line=string.format("${color %s}", color) .. line
		end	
		line = line:gsub("%%(+$*])", "%1")
		lines=lines .. line .. '
'
		i = i -1
	end	
	return lines
end

The code in red is commented out ; the code in green is added.

Further I would have to modify conkyconf so that option -l only works for members of the wheel group and print this for others:

		"You don't have read access to $log. Skipping logfile monitoring. "

This is actually what it does at the moment for normal users.

Non being allowed to read /var/log/messages as normal user is not a bug. Under ArchLinux however, you could add yourself to the “log” group and get read access to the logs.*

Perfecto mundi! Thank you Malcolm!

logrotate is started daily by cron (see /etc/cron.daily/logrotate) and conditions to rotate logs are specified in logrotate configuration file. In case of /var/log/messages it is “size +4096k” meaning - rotate when size exceeds 4MB. Regarding /etc/permissions.local - unfortunately, it is applied only when SuSEconfig is run, so next log rotation will reset permissions again.

Hi
OK, take a step back for a moment and decide what your really wanting
from the messages data, or just on the off chance the user sees
something important. If it’s important enough for the user to be
concerned then use something like sec to trigger an email or an snmp
alarm… sec could be configured to output data to a custom log file
for presentation as well. If you really want all the messages data,
pipe it out to a VT and use alt+ctrl+Fn just like the kernel log.

Else just create a custom log mirror messages and set the permissions
as required.


Cheers Malcolm °¿° (Linux Counter #276890)
openSUSE 12.2 (x86_64) Kernel 3.4.6-2.10-desktop
up 2 days 20:31, 4 users, load average: 0.33, 0.21, 0.16
CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU

On 2012-09-13 08:26, portsample wrote:
>
> malcolmlewis;2486652 Wrote:
>> Hi
>> Look at the file /etc/permissions.local it has some information :wink:
>>
>
> Perfecto mundi! Thank you Malcolm!

The correct place is “/etc/logrotate.d/syslog”. No, it will not be changed without telling you
(rcrpmconfigcheck).

The permissions.local file is not appropriate because it does not run every time logrotate runs.


Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

I add myself to the root group for this. Personally, I think the permissions should be more permissive, but I do what is needed to live with what we have.

On 2012-09-13 23:36, nrickert wrote:
>
> I add myself to the root group for this. Personally, I think the
> permissions should be more permissive, but I do what is needed to live
> with what we have.

No, I do not think they should be more permissive. That’s something you can do on your own
system under your responsibility, but not as a general rule for everybody’s system.


Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

ArchLinux has a log group for this. As a user, you would just need to add yourself to the log group.