-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2008-06-09 at 14:03 +0200, LLLActive@GMX.Net wrote:

Carlos E. R. wrote:

...

...

Also, why do i need to be root to read this? What to I change so I can read this without havign to su to root?

The log is probably readable by the group "root", so all you need is adding your user to that group, and login again.

Er ..., is that not as dangerous as in winblows adding users to Administration group and opening the barn door for all sorts of malware and viri? If you have to read the file, I'd rather copy the file with cron periodically to a users home directory else and allow read access for a particular user only. BUT, I think allowing read rights by anyone to this file could divulge too much vulnerable info for malicious users about the system.

:-)

I don't see the danger. You are not allowing anyone access to the log, you are allowing access only to those users that are in the 'root' group - and by default, that means nobody can read it. Notice that the user to be added to the group "root" is in fact the owner and root for the system. If he wants to do anything a normal user can't do, he simply logs in as root or uses "su". There is no new danger, I think. What we are doing is facilitating for him some maintenance tasks with some less hassle. We are not giving easier access to a nobody, but to the person that is the admin. Why would be the logs be readable by any group at all? If the intention is that no one should be able to read them at all, make the logs rw------- and be done with it. Some logs have those permissions, in fact. If even that is a problem, then add a new group to the system, like "logread", and edit the syslog config so that logs belong to that group instead of "root". Copying the logs periodically is a resource you have to allocate, aside from not very useful, the log is outdated. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFITUP9tTMYHG2NR9URAlBmAJ9WIHa4cuLjIELBNnW4/UZpVKXQSACeLBBE QMhQQm8kIMEDxor3zqYqn9o= =VWDS -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

John Andersen wrote:

On Mon, Jun 9, 2008 at 7:53 AM, Carlos E. R. wrote:

...

Notice that the user to be added to the group "root" is in fact the owner and root for the system. If he wants to do anything a normal user can't do, he simply logs in as root or uses "su". There is no new danger,

So you are saying a user added to the group "root" would not impose a danger of this user unwittingly running rm -Rf / and nuking the system?

Nope, it significantly reduces the danger. Simply being a member of the root group would not allow one to remove / since that would require write access, which isn't somehow automatically conferred just because a user in the root group. Secondly, since this user is already the admin & owner of the machine, he already has the root password. So, rather than allowing him read access to the log files through a group addition, you'd rather have the user log in as root, where he really *could* rm -rf / So, how is that safer? Joe -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Monday 09 June 2008 01:25:50 pm John Andersen wrote:

However, for the task at hand, permission to read /var/log/messages can be controlled in Yast under Miscellaneous Settings / File permissions by selecting "Easy"

That would be awesome - but I don't see anything under YaST that allows for File Permissions.

File Permissions: Settings for the permissions of certain system files are set according to the data in /etc/permissions.secure or /etc/permissions.easy.

And of course Root can mess with the specific settings in either of those files.

Interesting - looking at those, but I get easily lost. :P I should have thought of it earlier - I just changed messages under var/log to 755. Problem solved. -- kai www.filesite.org || www.4thedadz.com || www.perfectreign.com remember - a turn signal is a statement, not a request -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2008-06-09 at 13:48 -0700, Kai Ponte wrote:

I should have thought of it earlier - I just changed messages under var/log to 755.

Which _is_ dangerous, as you set it to be readable by all, and the logs can contain passwords and other sensitive data.

Problem solved.

For some time. The permissions you set will be dully restored. We'll wait patiently for your next question :-P - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFITa+ktTMYHG2NR9URAg3TAJ4sRvpaWKramWMTAMelDefm2dX7IgCfcuRm A+JAv95klxksf8nybpFrl48= =vVfx -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2008-06-09 at 17:32 -0700, Kai Ponte wrote:

...

The Monday 2008-06-09 at 13:48 -0700, Kai Ponte wrote:

...

I should have thought of it earlier - I just changed messages under var/log to 755.

Which _is_ dangerous, as you set it to be readable by all, and the logs can contain passwords and other sensitive data.

Huh?

I can't imagine that. I'll look through the logs. I would *hope* no one would put that sort of information in logs.

Leave it in the ntuser.dat file where it belongs! :P

Yes, some programs do write passwords in the log when they are set to very verbose mode. Ftp does, if I remember correctly. If you read the mans for syslog (I don't remember which one exactly) there is a facility named 'auth' and another one named 'authpriv'; the idea being, I think, that passwords went to the second one so that the admin could define stricter permissions for the second log. However, it doesn't work that well, I think. Logs have to be treated as sensitive data always.

...

...

Problem solved.

For some time. The permissions you set will be dully restored. We'll wait patiently for your next question :-P

Really?

Okay, this is annoying. Then I need a log reader that the average user can see.

We have told you how, in several voices :-P Okay, who has got to read those logs, the same user that is also root? Then simply add that user to the group "root". You can do that from the CLI or from YaST. Do some other people have to read those logs, or you don't want to do use the "root" group fearing it could be dangerous? Ok, then write the logs so that the belong to user root, group "logview" (for instance), and add those users to group "logview". Steps: Create the group "logview". Edit "/etc/syslog-ng/syslog-ng.conf". There should be a line: options { long_hostnames(off); sync(0); perm(0640); stats(3600); }; There are two other options, named group() and owner(). The documentation says: +--------------------------------------------------------------------------------------------------------------------------------------------------+ | Name | Accepted values | Description | Default | ... |---------------------------+--------------------+----------------------------------------------------------------------------------+--------------| | owner() | userid | The uid of the objects. | root | |---------------------------+--------------------+----------------------------------------------------------------------------------+--------------| | group() | groupid | The gid of the objects. | root | file:///usr/share/doc/packages/syslog-ng/html/index.html#options So this should work: options { long_hostnames(off); sync(0); perm(0640); group(logview); stats(3600); }; You also need to inform the rotate mechanism. Edit "/etc/logrotate.d/syslog-ng". There will be one or more entries like ....... { ... create 640 root root so change to: create 640 root logview This will suffice for the /var/log/messages file, but there are more you may want to read: there are several logrotate files that have that entry, change them if you want to read the corresponding compressed logs. You will also have to edit the appropriate configurations, like mysql, snort, etc, on their own configuration files. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFITdwVtTMYHG2NR9URAuUQAJ4oWa9u0mnwgYWxbYMR4FaGrQAuxACdHM16 Ai1YmyJxMt8sxPzdb0+5Fy8= =eqUb -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2008-06-09 at 12:18 -0700, Sloan wrote:

...

So you are saying a user added to the group "root" would not impose a danger of this user unwittingly running rm -Rf / and nuking the system?

Nope, it significantly reduces the danger. Simply being a member of the root group would not allow one to remove / since that would require write access, which isn't somehow automatically conferred just because a user in the root group.

Secondly, since this user is already the admin & owner of the machine, he already has the root password. So, rather than allowing him read access to the log files through a group addition, you'd rather have the user log in as root, where he really *could* rm -rf /

So, how is that safer?

Exactly :-) Perhaps a danger could be that if somebody on the networks gains access as that user, impersonating him or through some hole, then he would have access to logs and things. However, if the root has the same password as the 1st user by default on new novell/suse systems, and this will be known by hackers, the group wouldn't matter much :-p - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFITa3mtTMYHG2NR9URAg8BAKCG2vSMeGAy4apOjEt57HwUb8LGpACdF32C WAOpWjYCgmG0P4lvfrvwzUI= =zj/4 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org