* the lock function uses F_SETLK / F_SETLKW as a conditional wait.
It's more reliable and better for performance to close the
MOUNTED_LOCK file in unlock_mtab(), otherwise concurrent process will
be wait by while () { link() } loop instead on fcntl(F_SETLKW).
Thanks to Jeff Moyer <moyer@redhat.com> who found the problem two
year ago.
* when open(MOUNTED_LOCK) failed, we need to try everything again, but
the original code didn't zeroize "we_created_lockfile" and the old
version in particular case left lock_mtab() without locked /etc/mtab.
This is nasty bug.
* the original locking code had bad performance due too long sleep
(1s), between attempts. Now we're more aggressive and we use
5000ms. The result is that more processes is able to lock mtab in
short time slice.
Thanks to Peter Rockai <prockai@redhat.com> who found the problem
and suggest a first version of the code with usleep.
* now we don't count number of attempts anymore, but we count sum of
time which we spend in the mtab_lock(). The number of attempts is
not important (and it also depends on CPU performance, load,
scheduler, ...), the important thing is how long we spend with
locking. Now time limit is 30s.
Signed-off-by: Karel Zak <kzak@redhat.com>
This feature has been already supported by mount, but it wasn't accessible by
losetup command. Now you can use "losetup -r".
Signed-off-by: Karel Zak <kzak@redhat.com>
The mount uses /sbin/mount.<type> when the type is *defined* on
command line or in fstab only. It's not a consistent solution, because
we also support fylesystem type autodetection. The patch allows to
mount OCFS2 by label for example.
Signed-off-by: Karel Zak <kzak@redhat.com>
The original newgrp command doesn't expect group pasword in /etc/gshadow
although almost all distributions use this file (and the gpasswd command).
The newgrp from util-linux is deprecated and better is use shadow-utils only.
Unfortunately, shadow-utils are broken too (see RH version where is bugfix).
In this case it's better fix util-linux version at least...
Signed-off-by: Karel Zak <kzak@redhat.com>
If you compile --with-audit the hwclock tool reports changes in sys/hw clock to
audit system. The real long-term and final solution is probably add hooks for
/dev/rtc to kernel, but it's not implemented yet.
Signed-off-by: Steve Grubb <sgrubb@redhat.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
quote from rh150493:
The kernel code, when setting the BIOS clock notes that the clock time
ticks to the next second 0.5 seconds after adjusting it (see
linux/arch/i386/kernel/time.c).
hwclock --systohc sets the CMOS clock at the 1 second boundry and thus
causes the clock to be wrong by 500ms each time it is reset. If the
clock is set every shutdown then the clock will have a reboot-count
related drift as well as the natural drift problems of the clock. Note
that this also mucks up the drift calculations, of course.
Signed-off-by: Karel Zak <kzak@redhat.com>
The test detects how "hwclock --systohc" untune the clock. Now the hwclock
command causes the hw clock to be wrong by 500ms each time it is reset.
The test resets the clock 10 times and result is 5 sec difference between NTP
and the clock. That's a bug... and it has to bee fixed in a next commit.
Signed-off-by: Karel Zak <kzak@redhat.com>
The patch to allow "hwclock --rtc /dev/rtc1" and so on,
since "/dev/rtc" may not be there and "/dev/rtc0" may not be
the right answer either.
The "--rtc" is compatible with next Bryan Henderson's hwclock
versions.
Signed-off-by: David Brownell <david-b@pacbell.net>
Signed-off-by: Karel Zak <kzak@redhat.com>
The cal command generates output that depends on time(). For reliable
regression tests we need to use still same time. It seems that LD_PRELOAD is
pretty simple way.
Signed-off-by: Karel Zak <kzak@redhat.com>
This support includes:
* non-PAM version supports IPv6 ranges in /etc/usertty
* utmp records with IPv6 addresses
Based on patch by: Milan Zazrivec <mzazrivec@redhat.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
On 64-bit platforms such as x86_64, glibc is usually built with 32-bit
compatibility for various structures. One of them is utmp.
What this means is that gettimeofday(&ut.ut_tv, NULL) on x86_64 will
end up overwriting the first parts of ut_addr_v6, leading to garbage
in the utmp file.
Signed-off-by: Karel Zak <kzak@redhat.com>
The login omits pam_acct_mgmt & chauth_tok when authentication is skipped.
Authentication may be skipped, for example, during krlogin because Kerberos
already took care of it. The problem with skipping pam_acct_mgmt is that it
allows users to use the system when maybe they should not be allowed, such that
if they have a Kerberos ticket, the other checks do not apply.
If a user had to use password authentication, pam_acct_mgmt may reject the user
for several reasons: not allowed to use the system at this time, not allowed to
use this system, user's account has been disabled, etc. Why should these tests
be skipped just because the user has a ticket?
Same with pam_chauthtok: the user may have a valid ticket, but if their
password has expired, they need to enter a new one right now.
Signed-off-by: Karel Zak <kzak@redhat.com>
If you manage to exec login with a userid other than root, and its
input / output directed to a terminal for which it does not have
read/write access, it will attempt to proceed (and can potentially
hang forever -- but this hang has been fixed in a previous commit).
It's better to check if we have permissions for terminal rather than
do any useless things.
From: Jason Vas Dias <jvdias@redhat.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
The PAM session modules typically write to syslog when leaving the
session. The openlog() is way how define a "ident" for syslog messages.
Signed-off-by: Karel Zak <kzak@redhat.com>
Login tries to set a timeout in main() by SIGALARM. If any restartable system
call is entered, such system calls can block indefinitely and will NOT be
interrupted by the SIGALRM.
The bug appears when the login program is run for a terminal for which it
doens't have read or write permission.
In that case, login hung until manually killed by the administrator in its
tcsetattr(...) call at login.c, line 460:
/* Kill processes left on this tty */
tcsetattr(0,TCSAFLUSH,&ttt);
This may possibly be a kernel bug - instead of returning EIO / EPERM, the
kernel continously sends an infinite number of SIGTTOU signals to the process .
An 80MB strace log file was generated, consisting of >1,000,000 repetitions
of :
4964 11:00:18 ioctl(0, SNDCTL_TMR_CONTINUE or TCSETSF, {c_iflags=0x106,
c_oflags=0x1805, c_cflags=0x800000be, c_lflags=0x3b, c_line=0,
c_cc="\x03\x1c\x7f\x15\x04\x00\x01\x00\x11\x13\x1a\x00\x12\x0f\x17\x16\x00\x00\x00"})
= ? ERESTARTSYS (To be restarted)
4964 11:00:18 --- SIGTTOU (Stopped (tty output)) @ 0 (0) ---
4964 11:00:18 --- SIGTTOU (Stopped (tty output)) @ 0 (0) ---
Login's alarm signal handler DOES get the SIGALRM after the 60 second timeout,
and timedout() is called; but then timedout2 calls ioctl(0, TCSETA, &ti), which
also blocks, because the ioctl(0, TCSETSF...) of tcsetattr is in progress, and
the exit() call of timedout2 is never reached, and the tcsetattr call is
restarted.
From: Jason Vas Dias <jvdias@redhat.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
The login cannot ignore signals, because:
* SIGHUP is only way how inform session leader that controlling
tty goes away. The leader has to inform others processes in same
process group about the signal.
* SIGHUP/SIGTERM cannot kill wait(2)-ing login, we have to wait as long
as any child process exists. The PAM session has to be closed correctly.
* The child process (before setsid()) has to call exit() if a controlling
tty goes away.
This patch is inspired by patch from Red Hat that is very well tested for last
4 years in all Red Hat distros.
Signed-off-by: Karel Zak <kzak@redhat.com>
If for some reason the pam set credential call fails, it does not close the pam
session. pam open can mount drives, so calling pam close is important.
From: Steve Grubb <sgrubb@redhat.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
Karel Zak
Jim Meyering