Re: /var/log/btmp permission problem.
On Fri, Apr 08, 2005 at 02:30:02PM +0100, William Zhou wrote:
The message read as Excess permission or bad ownership on file
/var/log/btmp. After changing to 640, it stops complianting.
That's a little odd. From openssh-4.0p1/loginrec.c:
if((fst.st_mode (S_IRWXG | S_IRWXO)) || (fst.st_uid != 0)){
logit(Excess permission or bad ownership on file %s,
_PATH_BTMP);
goto out;
}
fst is a struct stat obtained from a stat call made on the btmp file.
st_mode is the set of permissions on the file. S_IRWXG is the RWX mask
for group according to the chmod(2) manpage, and S_IRWXO is the RWX
mask for other. ORing them together gives you a mask for all the
permissions given to anyone who is not the owner.
ANDing that mask with the st_mode will give you either 0044 (when the
permissions are 0644) or 0040 (when the permissions are 0640). This
value is always nonzero, so the if check should be succeeding in both
your cases (which means that sshd should be logging errors in both your
cases).
The only time sshd will refrain from logging this message is when no
permissions are granted to anyone except the owner, and when the owner
is root. Therefore, if we want to prevent this message from being
logged, we should be chmod 0600'ing the file, not 0640. (We create it
as root, so the owner should already be root.)
However, depending on the usage of the btmp file, it might be argued
that the LFS book is not the correct place to make this change -- maybe
the BLFS page on sshd would be better. I don't know if that's the case
(I rather suspect that it is not -- I don't think that allowing every
user to read all the bad login attempts is a good thing), but it is
possible.
pgpuoWl7uEMdV.pgp
Description: PGP signature
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
From Switzerland
Since 1924 our Official Swiss Pharm. has been the most trusted pharm. in the world, year after year. Unlike others, we allow you to order at your discretion, without any questions and with the Iron Clad Swiss Privacy Act assuring your order will be secure, delivered and all information will be kept private. This weeks specials are Pain-klllers, sleep-aids(Amb/Val), sexx-aids(Ci/Vi) http://Deanne.b7x.net/ph/864/stagnant Did this reach you in error please let us know and your info will be deleted from our database http://Deanne.y73.net/f.php -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS 6.1-testing issues
On Fri, Apr 08, 2005 at 11:17:18PM -0500, Bruce Dubbs wrote: Sorry. I should have specified. I get ^? printed on the screen in insert mode or in :ex mode. No characters are erased. A Ctrl-h works properly as a backspace should. I cannot reproduce this on any of the builds I've done since the middle of March (i.e. the only ones I have around). showkey says the backspace keycode is 14. dumpkeys says keycode 14 is Delete. Same here, so I doubt that is the problem. Perhaps vim somehow miscompiled? I have full logs for vim if you want to compare. -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS 6.1-testing issues
Archaic wrote: On Fri, Apr 08, 2005 at 11:17:18PM -0500, Bruce Dubbs wrote: Sorry. I should have specified. I get ^? printed on the screen in insert mode or in :ex mode. No characters are erased. A Ctrl-h works properly as a backspace should. I cannot reproduce this on any of the builds I've done since the middle of March (i.e. the only ones I have around). showkey says the backspace keycode is 14. dumpkeys says keycode 14 is Delete. Same here, so I doubt that is the problem. Perhaps vim somehow miscompiled? I have full logs for vim if you want to compare. Yes, that would be good. Please send off list. BTW, I have fixed the symptom with an addition to /etc/vimrc with: if term == linux set t_kb=^? endif where the ^? is really a delete character created by a ctrl-v BS-key. I would really like to find the problem and fix it however. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
