Bug 24880 - login: utmp implementation uses struct flock with fcntl64
Summary: login: utmp implementation uses struct flock with fcntl64
Status: RESOLVED FIXED
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: 2.31
: P2 normal
Target Milestone: 2.31
Assignee: Florian Weimer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-08-05 15:38 UTC by Florian Weimer
Modified: 2020-01-17 14:02 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 Florian Weimer 2019-08-05 15:38:15 UTC
Commit 06ab719d30b01da401150068054d3b8ea93dd12f ("Fix Linux fcntl OFD locks for non-LFS architectures (BZ#20251)") introduced the use of fcntl64 into the utmp implementation.  However, the lock file structure was not updated to struct flock64 at that point.
Comment 1 Adhemerval Zanella 2019-08-05 18:54:36 UTC
Since the login/utmp_file.c is the only place where require call fcntl as a cancellation entrypoint, I think we can simplify and just remove __fcntl64_nocancel.  On login/utmp_file.c it will be something like:

--
#define LOCK_FILE(fd, type) \
{
  struct flock64 fl;                                                            \
  int state;                                                                    \
  int ret;                                                                      \
  [...]
  __libc_ptf_call (__pthread_setcancelstate,                                    \
                   (PTHREAD_CANCEL_DISABLE, &state), 0);                        \
  ret = __fcntl64 ((fd), F_SETLKW, &fl);                                        \
  __libc_ptf_call (__pthread_setcancelstate, (state, NULL), 0);                 \
  if (ret < 0)

[...]

#define UNLOCK_FILE(fd) \
  fl.l_type = F_UNLCK;                                                          \
  __libc_ptf_call (__pthread_setcancelstate,                                    \
                   (PTHREAD_CANCEL_DISABLE, &state), 0);                        \
  _fcntl64 ((fd), F_SETLKW, &fl);                                               \
  __libc_ptf_call (__pthread_setcancelstate, (state, NULL), 0);

Both the sysdeps/posix/fdopendir.c and sysdeps/posix/opendir.c are not calling fcntl as cancellation entrypoints, so there is no need to call the _nocancel variant.

It also allows remove sysdeps/unix/sysv/linux/fcntl_nocancel.c and move the required code to sysdeps/unix/sysv/linux/fcntl64.c.
Comment 2 Florian Weimer 2019-08-06 08:48:28 UTC
It may also make to treat the fcntl call as a cancellation point instead (although it needs cleanup for the SIGALRM handler).
Comment 3 Sourceware Commits 2019-08-15 14:28:58 UTC
The master branch has been updated by Florian Weimer <fw@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=0d5b2917530ccaf8ad312dfbb7bce69d569c23ad

commit 0d5b2917530ccaf8ad312dfbb7bce69d569c23ad
Author: Florian Weimer <fweimer@redhat.com>
Date:   Thu Aug 15 16:09:20 2019 +0200

    login: Use struct flock64 in utmp [BZ #24880]
    
    Commit 06ab719d30b01da401150068054d3b8ea93dd12f ("Fix Linux fcntl OFD
    locks for non-LFS architectures (BZ#20251)") introduced the use of
    fcntl64 into the utmp implementation.  However, the lock file
    structure was not updated to struct flock64 at that point.
Comment 4 Florian Weimer 2019-08-15 14:31:22 UTC
Fixed in glibc 2.31.
Comment 5 Sourceware Commits 2020-01-17 14:02:25 UTC
The release/2.30/master branch has been updated by Florian Weimer <fw@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=dbbd748c5f69a2fb4d5d305df2ce15b9e69a46ef

commit dbbd748c5f69a2fb4d5d305df2ce15b9e69a46ef
Author: Florian Weimer <fweimer@redhat.com>
Date:   Thu Aug 15 16:09:20 2019 +0200

    login: Use struct flock64 in utmp [BZ #24880]
    
    Commit 06ab719d30b01da401150068054d3b8ea93dd12f ("Fix Linux fcntl OFD
    locks for non-LFS architectures (BZ#20251)") introduced the use of
    fcntl64 into the utmp implementation.  However, the lock file
    structure was not updated to struct flock64 at that point.
    
    (cherry picked from commit 0d5b2917530ccaf8ad312dfbb7bce69d569c23ad)