Bug 6700 - utmpname(3) returns interger but man page says void and doesnot returns with failure if file not found.
Summary: utmpname(3) returns interger but man page says void and doesnot returns with ...
Status: RESOLVED INVALID
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: unspecified
: P2 minor
Target Milestone: ---
Assignee: Ulrich Drepper
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-06-27 11:18 UTC by Halesh S
Modified: 2014-07-04 06:33 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Halesh S 2008-06-27 11:18:26 UTC
Hi,

In glibc 2.7 I found, Man page of utmpname(3) says its prototype as...

            void utmpname(const char *file);

But if we check the source in login/utmpname.c
int
__utmpname (const char *file)
{
....
....
}

This is conflicting one, so man page needs to be fixed.

And utmpname(3) does not reports failure if the file that we pass and
it does not exists.

The testcase is...
$ ls -l utmp1
ls: utmp1: No such file or directory

$ cat test.c
#include <stdio.h>
#include <utmp.h>

int main()
{
     printf("%d\n", utmpname("./utmp1"));
}

$ gcc test.c -o test
$ ./test
0

This intern affecting the other commands like who (1).

$ who ./utmp1
$ echo $?
0

**Even utmp1 file not exists, its exit status is zero.

Fixing the issue in utmp will fix the other dependencies.

Patch to fix the issue
=======================

--- utmpname.c.old      2008-06-24 16:36:27.000000000 +0530
+++ utmpname.c  2008-06-24 16:37:12.000000000 +0530
@@ -21,6 +21,7 @@
 #include <stdlib.h>
 #include <string.h>
 #include <utmp.h>
+#include <sys/stat.h>

 #include "utmp-private.h"

@@ -39,6 +40,12 @@
 __utmpname (const char *file)
 {
  int result = -1;
+ struct stat buf;
+
+  if (stat(file, &buf) != 0)
+   {
+        return result;
+   }

 __libc_lock_lock (__libc_utmp_lock);


Thanks,
Halesh
Comment 1 Halesh S 2008-06-27 12:37:15 UTC
Hi Ulrich,

In the link 
http://www.gnu.org/software/libtool/manual/libc/Manipulating-the-Database.html

It has mentioned that 
"The utmpname function returns a value of 0 if the new name was successfully 
stored, and a value of -1 to indicate an error. Note that utmpname does not try 
to open the database, and that therefore the return value does not say anything 
about whether the database can be successfully opened."

This means utmpname(3) never reports faiure if database doesnot exists.

In readutmp.c of coreutils it has mentioned 
"Solaris' utmpname returns 1 upon success -- which is contrary to what the GNU 
libc version does.  In addition, older GNU libc versions are actually void."

But GNU libc utmpname returns -1 on failure, May it returns differen values on 
success I think it does not causes any contrary with Solaris utmpname failure.

Even we did not open database can we include the database existance checking, 
Will it causes any effects. 

As mentioned above this may resolve who(1) problem, and which helps in 
processing other commands based on who(1) o/p.

Thanks,
Halesh
Comment 2 Petr Baudis 2008-06-28 23:19:38 UTC
Note that the manpage does not come from libc but linux-manpages: 
http://www.kernel.org/doc/man-pages/
Comment 3 Halesh S 2008-06-30 07:10:04 UTC
Thanks Petr Baudis.

I have raised a bug for the manpage after refering your mentione link.
http://bugzilla.kernel.org/show_bug.cgi?id=11011

Can you please verfiy the second part of this defect, about the return value 
when file not found?



Comment 4 Ulrich Drepper 2008-08-13 04:31:49 UTC
It makes no sense for utmpname to check whether the file exists.  It does not
open the file so the file might not yet exist at the time of the call or it
might disappear before it is actually used.  The code is fine.