/var/log/btmp permission problem.

Bryan Kadzban bryan at kadzban.is-a-geek.net
Fri Apr 8 09:52:06 PDT 2005


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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20050408/f02df3eb/attachment.sig>


More information about the lfs-dev mailing list