The get_linux_version() function is Linux-specific.
Work around it in a few places.
[kzak@redhat.com: split the original patch to small patches]
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Signed-off-by: Karel Zak <kzak@redhat.com>
GNU/Hurd uses linux-like swapspace, so mkswap makes sense on
non-linux platforms too.
[kzak@redhat.com: split the original patch to small patches]
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Signed-off-by: Karel Zak <kzak@redhat.com>
write(1) selects a wrong tty, because there is not a proper
check of tty group ownership:
$ write kzak
write: kzak is logged in more than once; writing to tty7
write: /dev/tty7: Permission denied
$ ls -la /dev/tty7
crw--w---- 1 root root 4, 7 2008-07-04 00:32 /dev/tty7
^^^^
$ ls -la /usr/bin/write
-rwxr-sr-x 1 root tty 11864 2008-04-02 16:24 /usr/bin/write
^ ^^^
We have to check for tty group owner, because we don't have
permissions to write to arbitrary tty.
Fixed version:
$ write kzak
write: kzak is logged in more than once; writing to pts/6
^^^^
Message from test@nb on pts/7 at 15:22 ...
^C
$ ls -la /dev/pts/6
crw--w---- 1 kzak tty 136, 6 2008-07-07 15:35 /dev/pts/6
^^^
Addresses-Red-Hat-Bugzilla: #454252
Signed-off-by: Karel Zak <kzak@redhat.com>
The new loop auto-destruct feature detaches automatically loop devices
when no longer used. This means they are detached with the umount()
call. But when we call umount with -d, del_loop() is called and fails
because the ioctl() returns ENXIO. We have to check for autoclear
loop devices rather than blindly call del_loop().
Reported-by: Matthias Koenig <mkoenig@suse.de>
Signed-off-by: Karel Zak <kzak@redhat.com>
Unfortunately, the current libselinux implementation of
is_selinux_enabled() returns -1 on error. This behavior is
undocumented.
The proper solution is to use "if (is_selinux_enabled() > 0)".
Signed-off-by: Karel Zak <kzak@redhat.com>
Currently if I mount a file system without labels, it works fine, but
later or SELinux will start printing denials and stopping certain
applications from working. It would be nice if the mount command
checked it in selinux mode.
Addresses-Red-Hat-Bugzilla: #390691
Signed-off-by: Karel Zak <kzak@redhat.com>
It's a pity that hwclock first tries to read the clock when running
hwclock --systohc --noadjfile --utc
and exits as this fails. I cannot see a reason to read first in that
case.
Old version:
# hwclock --systohc --noadjfile --utc --debug
hwclock from util-linux-ng 2.14
Using /dev interface to clock.
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
/dev/rtc does not have interrupt functions. Waiting in loop for time
from /dev/rtc to change
...got clock tick
Time read from Hardware Clock: 2008/06/17 11:18:24
Hw clock time : 2008/06/17 11:18:24 = 1213701504 seconds since 1969
Time elapsed since reference time has been 0.904855 seconds.
Delaying further to reach the next full second.
Setting Hardware Clock to 11:18:24 = 1213701504 seconds since 1969
ioctl(RTC_SET_TIME) was successful.
New version:
# hwclock --systohc --noadjfile --utc --debug
hwclock from util-linux-ng 2.14
Using /dev interface to clock.
Assuming hardware clock is kept in UTC time.
Time elapsed since reference time has been 0.572151 seconds.
Delaying further to reach the next full second.
Setting Hardware Clock to 11:18:52 = 1213701532 seconds since 1969
ioctl(RTC_SET_TIME) was successful.
Addresses-Debian-Bug: #478663
Signed-off-by: Karel Zak <kzak@redhat.com>
This patch allows "tolerant" behavior, i.e. proceeding even if
priority could not be set. This might be of use in case something
(selinux, old kernel, etc.) does not allow the requested scheduling
priority to be set.
This could be to some extend done as follows:
ionice -c3 command || command
but the downside is that one could not really tell if what failed was
setting priority or command itself, which could result in duplicate
command run.
This patch solves the situation, so that user can do
ionice -t -c3 command
Addresses-Red-Hat-Bugzilla: #443842
Signed-off-by: Lubomir Kundrak <lkundrak@redhat.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
Currently, if hwclock is given the --noadjfile option it will
nevertheless display information about the drift rate when invoked with
the --debug option.
Signed-off-by: Matthias Koenig <mkoenig@suse.de>
The a.out.h header is not friendly to portable systems (iow, those that
lack a.out support), and since the defines are only used in a cheesy magic,
just use the magic constants. It's not like they're ever going to change.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Read the magic bytes into signed chars instead of vanilla chars in
order to ensure consistent results even on systems whose char type has
no sign. Eliminate spurious parentheses in return statements.
Correct grammatical errors in comments.
Signed-off-by: James Youngman <jay@gnu.org>
the Discordian date utility ddate gives the 11th, 12th and 13th of the month as
the "11st", "12nd" and "13rd". Unless this is a religious thing, please apply
the patch below.
Signed-off-by: Volker Schatz <oss@volkerschatz.com>
Writing "suspend" to /sys/power/state does nothing.
Even "man rtcwake" says that default should be "standby" :)
Signed-off-by: Paulius Zaleckas <paulius.zaleckas@teltonika.lt>
Signed-off-by: Karel Zak <kzak@redhat.com>
While working on french translation of the Linux Man Pages, I've found a
small typo in mount.8.
Only one wrong letter : the option "osyncis_o_sync" for XFS filesystem
is erroneously replaced by "osyncis_d_sync" (the previous option).
Signed-off-by: Christophe Blaess <Christophe@Blaess.fr>
Signed-off-by: Karel Zak <kzak@redhat.com>
The command
# mount -oremount <spec> <dir>
doesn't read fstab or mtab. This is expected behaviour. Unfortunately,
we have to care about the internal loop= option which is generated and
maintained by mount(8)/umount(8). The loop= option has to be persistent.
How to reproduce this bug:
# mount -o loop /home/images/vfat.img /mnt/img; grep vfat /etc/mtab; \
mount -o remount,ro /home/images/vfat.img /mnt/img; grep vfat /etc/mtab;
/home/images/vfat.img /mnt/img vfat rw,loop=/dev/loop0 0 0
/home/images/vfat.img /mnt/img vfat ro 0 0
Reported-By: David Chinner <dgc@sgi.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
The fdisk programs do not recognize the partition types used by VMware
ESX. They show up as "unknown".
Addresses-Red-Hat-Bugzilla: #447023
Signed-off-by: Karel Zak <kzak@redhat.com>
setarch.c:248: error: 'ADDR_NO_RANDOMIZE' undeclared (first use in this function)
setarch.c:248: error: (Each undeclared identifier is reported only once
setarch.c:248: error: for each function it appears in.)
setarch.c:251: error: 'FDPIC_FUNCPTRS' undeclared (first use in this function)
setarch.c:257: error: 'ADDR_COMPAT_LAYOUT' undeclared (first use in this function)
setarch.c:260: error: 'READ_IMPLIES_EXEC' undeclared (first use in this function)
Linux gzp1 2.4.36.1-gzp1 #1 SMP Tue Feb 19 10:23:48 CET 2008 i686 GNU/Linux
Reported-By: Gabor Z. Papp <gzp@papp.hu>
Signed-off-by: Karel Zak <kzak@redhat.com>
The idle class is safe for non-root users since 2.6.25.
http://lwn.net/Articles/266256/
Addresses-Red-Hat-Bugzilla: #443823
Signed-off-by: Karel Zak <kzak@redhat.com>
A while back I found a couple audit log injection attacks which became
CVE-2007-3102. I forgot to look at login to see if its vulnerable and Mirek
found that it is. To verify the problem, type:
root addr=xyz.com
for the account name while logging in. It will look like root logged in with
an address of xyz.com.
Signed-off-by: Steve Grubb <sgrubb@redhat.com>
Samuel Thibault
Karel Zak
Cai Qian
Lubomir Kundrak
Matthias Koenig
Mike Frysinger
James Youngman
Gabor Kelemen
Volker Schatz
Paulius Zaleckas
Christophe Blaess
Clytie Siddall
Benno Schulenberg
Marco Colombo
Petr Pisar
Steve Grubb