openafs.git
7 months agoMerge tag 'openafs-stable-1_6_24' into openafs-stable-1_6_x openafs-stable-1_6_x
Benjamin Kaduk [Tue, 22 Oct 2019 23:05:45 +0000]
Merge tag 'openafs-stable-1_6_24' into openafs-stable-1_6_x

Join the history of the security release into the
1.6.x stable release branch.

Change-Id: I5e75a3f9d475bacc39bbd8539d561d5e9395f300

7 months agoMake OpenAFS 1.6.24 openafs-stable-1_6_24
Benjamin Kaduk [Tue, 22 Oct 2019 16:39:02 +0000]
Make OpenAFS 1.6.24

Update version strings for the 1.6.24 release.

Change-Id: I0a453d32018cc84b491c5d7f897229c365958054

7 months agoUpdate NEWS for 1.6.24
Benjamin Kaduk [Tue, 22 Oct 2019 07:08:36 +0000]
Update NEWS for 1.6.24

Release notes for the OpenAFS 1.6.24 security release.

Change-Id: Id12988da9e71dc338bf259d4ac32ceaa6da70197

7 months agoOPENAFS-SA-2019-003: ubik: Avoid unlocked ubik_currentTrans deref
Andrew Deason [Mon, 16 Sep 2019 19:06:53 +0000]
OPENAFS-SA-2019-003: ubik: Avoid unlocked ubik_currentTrans deref

Currently, SVOTE_Debug/SVOTE_DebugOld examine some ubik internal state
without any locks, because the speed of these functions is more
important than accuracy.

However, one of the pieces of data we examine is ubik_currentTrans,
which we dereference to get ubik_currentTrans->type. ubik_currentTrans
could be set to NULL while this code is running, so there is a small
chance of this code causing a segfault, if SVOTE_Debug() is running
when the current transaction ends.

We only ever initialize ubik_currentTrans as a write transation (via
SDISK_Begin), so this check is pointless anyway. Accordingly, skip the
type check, and always assume that any active transaction is a write
transaction.  This means we only ever access ubik_currentTrans once,
avoiding any risk of the value changing between accesses (and we no
longer need to dereference it, anyway).

Note that, since ubik_currentTrans is not marked as 'volatile', some C
compilers, with certain options, can and do assume that its value will
not change between accesses, and thus only fetch the pointer value once.
This avoids the risk of NULL dereference (and thus, crash, if pointer
stores/loads are atomic), but the value pointed to by ubik_currentTrans->type
would be incorrect when the transaction ends during the execution of
SVOTE_Debug().

Reviewed-on: https://gerrit.openafs.org/13915
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 6ec46ba7773089e1549d27a0d345afeca65c9472)

Reviewed-on: https://gerrit.openafs.org/13918
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 213b9dc386ff89a14379313ee8ec09280f130a29)

Change-Id: I0ddbc2309de09a629150a6b3825e1aa8bda8b910
Reviewed-on: https://gerrit.openafs.org/13923
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

7 months agoOPENAFS-SA-2019-002: Zero all server RPC args
Andrew Deason [Thu, 8 Aug 2019 02:19:47 +0000]
OPENAFS-SA-2019-002: Zero all server RPC args

Currently, our server-side RPC argument-handling code generated from
rxgen initializes complex arguments like so (for example, in
_RXAFS_BulkStatus):

    AFSCBFids FidsArray;
    AFSBulkStats StatArray;
    AFSCBs CBArray;
    AFSVolSync Sync;

    FidsArray.AFSCBFids_val = 0;
    FidsArray.AFSCBFids_len = 0;
    CBArray.AFSCBs_val = 0;
    CBArray.AFSCBs_len = 0;
    StatArray.AFSBulkStats_val = 0;
    StatArray.AFSBulkStats_len = 0;

This is done for any input or output arguments, but only for types we
need to free afterwards (arrays, usually). We do not do this for
simple types, like single flat structs. In the above example, we do
this for the arrays FidsArray, StatArray, and CBArray, but 'Sync' is
not initialized to anything.

If some server RPC handlers never set a value for an output argument,
this means we'll send uninitialized stack memory to our peer.
Currently this can happen in, for example,
MRXSTATS_RetrieveProcessRPCStats if 'rxi_monitor_processStats' is
unset (specifically, the 'clock_sec' and 'clock_usec' arguments are
never set when rx_enableProcessRPCStats() has not been called).

To make sure we cannot send uninitialized data to our peer, change
rxgen to instead 'memset(&arg, 0, sizeof(arg));' for every single
parameter. Using memset in this way just makes this a little simpler
inside rxgen, since all we need to do this is the name of the
argument.

With this commit, the rxgen-generated code for the above example now
looks like this:

    AFSCBFids FidsArray;
    AFSBulkStats StatArray;
    AFSCBs CBArray;
    AFSVolSync Sync;

    memset(&FidsArray, 0, sizeof(FidsArray));
    memset(&CBArray, 0, sizeof(CBArray));
    memset(&StatArray, 0, sizeof(StatsArray));
    memset(&Sync, 0, sizeof(Sync));

Reviewed-on: https://gerrit.openafs.org/13914
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 93aee3cf40622993b95bd1af77080a31670c24bb)

Reviewed-on: https://gerrit.openafs.org/13917
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit fcaac44f845d18d6fd5d2f3685db11118d8f8626)

Change-Id: Ic096570e9c894fb05d084ba451beabda3bb295e2
Reviewed-on: https://gerrit.openafs.org/13922
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

7 months agoOPENAFS-SA-2019-001: Skip server OUT args on error
Andrew Deason [Thu, 8 Aug 2019 01:50:47 +0000]
OPENAFS-SA-2019-001: Skip server OUT args on error

Currently, part of our server-side RPC argument-handling code that's
generated from rxgen looks like this (for example):

    z_result = SRXAFS_BulkStatus(z_call, &FidsArray, &StatArray, &CBArray, &Sync);
    z_xdrs->x_op = XDR_ENCODE;
    if ((!xdr_AFSBulkStats(z_xdrs, &StatArray))
         || (!xdr_AFSCBs(z_xdrs, &CBArray))
         || (!xdr_AFSVolSync(z_xdrs, &Sync)))
            z_result = RXGEN_SS_MARSHAL;
fail:
    [...]
    return z_result;

When the server routine for implementing the RPC results a non-zero
value into z_result, the call will be aborted. However, before we
abort the call, we still call the xdr_* routines with XDR_ENCODE for
all of our output arguments. If the call has not already been aborted
for other reasons, we'll serialize the output argument data into the
Rx call. If we push more data than can fit in a single Rx packet for
the call, then we'll also send that data to the client. Many server
routines for implementing RPCs do not initialize the memory inside
their output arguments during certain errors, and so the memory may be
leaked to the peer.

To avoid this, just jump to the 'fail' label when a nonzero 'z_result'
is returned. This means we skip sending the output argument data to
the peer, but we still free any argument data that needs freeing, and
record the stats for the call (if needed). This makes the above
example now look like this:

    z_result = SRXAFS_BulkStatus(z_call, &FidsArray, &StatArray, &CBArray, &Sync);
    if (z_result)
        goto fail;
    z_xdrs->x_op = XDR_ENCODE;
    if ((!xdr_AFSBulkStats(z_xdrs, &StatArray))
         || (!xdr_AFSCBs(z_xdrs, &CBArray))
         || (!xdr_AFSVolSync(z_xdrs, &Sync)))
            z_result = RXGEN_SS_MARSHAL;
fail:
    [...]
    return z_result;

Reviewed-on: https://gerrit.openafs.org/13913
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit ea276e83e37e5bd27285a3d639f2158639172786)

Reviewed-on: https://gerrit.openafs.org/13916
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 5a3d1b62810fc8cc7b37a737b4f5f1912bc614f9)

Change-Id: Ia54b06399b1f8a05a560ec7560580783d3e64b9d
Reviewed-on: https://gerrit.openafs.org/13921
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

7 months agoOPENAFS-SA-2019-003: ubik: Avoid unlocked ubik_currentTrans deref 23/13923/2
Andrew Deason [Mon, 16 Sep 2019 19:06:53 +0000]
OPENAFS-SA-2019-003: ubik: Avoid unlocked ubik_currentTrans deref

Currently, SVOTE_Debug/SVOTE_DebugOld examine some ubik internal state
without any locks, because the speed of these functions is more
important than accuracy.

However, one of the pieces of data we examine is ubik_currentTrans,
which we dereference to get ubik_currentTrans->type. ubik_currentTrans
could be set to NULL while this code is running, so there is a small
chance of this code causing a segfault, if SVOTE_Debug() is running
when the current transaction ends.

We only ever initialize ubik_currentTrans as a write transation (via
SDISK_Begin), so this check is pointless anyway. Accordingly, skip the
type check, and always assume that any active transaction is a write
transaction.  This means we only ever access ubik_currentTrans once,
avoiding any risk of the value changing between accesses (and we no
longer need to dereference it, anyway).

Note that, since ubik_currentTrans is not marked as 'volatile', some C
compilers, with certain options, can and do assume that its value will
not change between accesses, and thus only fetch the pointer value once.
This avoids the risk of NULL dereference (and thus, crash, if pointer
stores/loads are atomic), but the value pointed to by ubik_currentTrans->type
would be incorrect when the transaction ends during the execution of
SVOTE_Debug().

Reviewed-on: https://gerrit.openafs.org/13915
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 6ec46ba7773089e1549d27a0d345afeca65c9472)

Reviewed-on: https://gerrit.openafs.org/13918
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 213b9dc386ff89a14379313ee8ec09280f130a29)

Change-Id: I0ddbc2309de09a629150a6b3825e1aa8bda8b910
Reviewed-on: https://gerrit.openafs.org/13923
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

7 months agoOPENAFS-SA-2019-002: Zero all server RPC args 22/13922/3
Andrew Deason [Thu, 8 Aug 2019 02:19:47 +0000]
OPENAFS-SA-2019-002: Zero all server RPC args

Currently, our server-side RPC argument-handling code generated from
rxgen initializes complex arguments like so (for example, in
_RXAFS_BulkStatus):

    AFSCBFids FidsArray;
    AFSBulkStats StatArray;
    AFSCBs CBArray;
    AFSVolSync Sync;

    FidsArray.AFSCBFids_val = 0;
    FidsArray.AFSCBFids_len = 0;
    CBArray.AFSCBs_val = 0;
    CBArray.AFSCBs_len = 0;
    StatArray.AFSBulkStats_val = 0;
    StatArray.AFSBulkStats_len = 0;

This is done for any input or output arguments, but only for types we
need to free afterwards (arrays, usually). We do not do this for
simple types, like single flat structs. In the above example, we do
this for the arrays FidsArray, StatArray, and CBArray, but 'Sync' is
not initialized to anything.

If some server RPC handlers never set a value for an output argument,
this means we'll send uninitialized stack memory to our peer.
Currently this can happen in, for example,
MRXSTATS_RetrieveProcessRPCStats if 'rxi_monitor_processStats' is
unset (specifically, the 'clock_sec' and 'clock_usec' arguments are
never set when rx_enableProcessRPCStats() has not been called).

To make sure we cannot send uninitialized data to our peer, change
rxgen to instead 'memset(&arg, 0, sizeof(arg));' for every single
parameter. Using memset in this way just makes this a little simpler
inside rxgen, since all we need to do this is the name of the
argument.

With this commit, the rxgen-generated code for the above example now
looks like this:

    AFSCBFids FidsArray;
    AFSBulkStats StatArray;
    AFSCBs CBArray;
    AFSVolSync Sync;

    memset(&FidsArray, 0, sizeof(FidsArray));
    memset(&CBArray, 0, sizeof(CBArray));
    memset(&StatArray, 0, sizeof(StatsArray));
    memset(&Sync, 0, sizeof(Sync));

Reviewed-on: https://gerrit.openafs.org/13914
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 93aee3cf40622993b95bd1af77080a31670c24bb)

Reviewed-on: https://gerrit.openafs.org/13917
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit fcaac44f845d18d6fd5d2f3685db11118d8f8626)

Change-Id: Ic096570e9c894fb05d084ba451beabda3bb295e2
Reviewed-on: https://gerrit.openafs.org/13922
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

7 months agoOPENAFS-SA-2019-001: Skip server OUT args on error 21/13921/2
Andrew Deason [Thu, 8 Aug 2019 01:50:47 +0000]
OPENAFS-SA-2019-001: Skip server OUT args on error

Currently, part of our server-side RPC argument-handling code that's
generated from rxgen looks like this (for example):

    z_result = SRXAFS_BulkStatus(z_call, &FidsArray, &StatArray, &CBArray, &Sync);
    z_xdrs->x_op = XDR_ENCODE;
    if ((!xdr_AFSBulkStats(z_xdrs, &StatArray))
         || (!xdr_AFSCBs(z_xdrs, &CBArray))
         || (!xdr_AFSVolSync(z_xdrs, &Sync)))
            z_result = RXGEN_SS_MARSHAL;
fail:
    [...]
    return z_result;

When the server routine for implementing the RPC results a non-zero
value into z_result, the call will be aborted. However, before we
abort the call, we still call the xdr_* routines with XDR_ENCODE for
all of our output arguments. If the call has not already been aborted
for other reasons, we'll serialize the output argument data into the
Rx call. If we push more data than can fit in a single Rx packet for
the call, then we'll also send that data to the client. Many server
routines for implementing RPCs do not initialize the memory inside
their output arguments during certain errors, and so the memory may be
leaked to the peer.

To avoid this, just jump to the 'fail' label when a nonzero 'z_result'
is returned. This means we skip sending the output argument data to
the peer, but we still free any argument data that needs freeing, and
record the stats for the call (if needed). This makes the above
example now look like this:

    z_result = SRXAFS_BulkStatus(z_call, &FidsArray, &StatArray, &CBArray, &Sync);
    if (z_result)
        goto fail;
    z_xdrs->x_op = XDR_ENCODE;
    if ((!xdr_AFSBulkStats(z_xdrs, &StatArray))
         || (!xdr_AFSCBs(z_xdrs, &CBArray))
         || (!xdr_AFSVolSync(z_xdrs, &Sync)))
            z_result = RXGEN_SS_MARSHAL;
fail:
    [...]
    return z_result;

Reviewed-on: https://gerrit.openafs.org/13913
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit ea276e83e37e5bd27285a3d639f2158639172786)

Reviewed-on: https://gerrit.openafs.org/13916
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 5a3d1b62810fc8cc7b37a737b4f5f1912bc614f9)

Change-Id: Ia54b06399b1f8a05a560ec7560580783d3e64b9d
Reviewed-on: https://gerrit.openafs.org/13921
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

14 months agoLinux_5.0: Use super_block flags instead of Mount flags when filling sb 51/13451/2
Cheyenne Wills [Thu, 17 Jan 2019 23:00:37 +0000]
Linux_5.0: Use super_block flags instead of Mount flags when filling sb

In Kernel commit e262e32d6bde0f77fb0c95d977482fc872c51996
the mount flags (MS_) were moved from uapi/linux/fs.h to
uapi/linux/mount.h. This caused a compile failure in
src/afs/LINUX/osi_vfsops.c

The Linux documentation in uapi/linux/mount.h indicates that the MS_
(mount) flags should only be used when calling sys_mount and filesystems
should use the SB_ (super_block) equivalent.

src/afs/LINUX/osi_vfsops.c utilized the mount flag MS_NOATIME while
filling the super_block.  Changed to use SB_NOATIME (which has the same
numeric value as MS_NOATIME) if available.

Reviewed-on: https://gerrit.openafs.org/13432
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 3969bbca6017eb0ce6e1c3099b135f210403f661)

Reviewed-on: https://gerrit.openafs.org/13440
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
(cherry picked from commit 25829aaef319728e30fc45895e8945438e4dc719)

Change-Id: I495c55e663a763d640a27403b678e41635b851d7
Reviewed-on: https://gerrit.openafs.org/13451
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

14 months agoRedhat: correct path to kernel module in dkms.config 50/13450/2
Cheyenne Wills [Wed, 28 Nov 2018 22:45:20 +0000]
Redhat: correct path to kernel module in dkms.config

This fix corrects some annoying error and warning messages during
dkms install or uninstall.

Install:
DKMS: build completed.

openafs:
Running module version sanity check.
ERROR: modinfo: could not open /lib/modules/2.6.32-754.6.3.el6.x
86_64/weak-updates/openafs.ko: No such file or directory
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/2.6.32-754.6.3.el6.x86_64/extra/
Adding any weak-modules
WARNING: Can't read module /lib/modules/2.6.32-754.6.3.el6.x86_6
4/weak-updates/openafs.ko: No such file or directory
egrep: /lib/modules/2.6.32-754.6.3.el6.x86_64//weak-updates/open
afs.ko: No such file or directory

Remove
Status: Before uninstall, this module version was ACTIVE on this
kernel.
Removing any linked weak-modules
rmdir: failed to remove `.': Invalid argument
WARNING: Can't read module /lib/modules/2.6.32-754.6.3.el6.x86_6
4/weak-updates/openafs.ko: No such file or directory
egrep: /lib/modules/2.6.32-754.6.3.el6.x86_64//weak-updates/open
afs.ko: No such file or directory

openafs.ko:
 - Uninstallation
   - Deleting from:/lib/modules/2.6.32-754.6.3.el6.x86_64/extra/
 - Original module
   - No original module was found for this module on this kernel
   - Use the dkms install command to reinstall any previous
   module version.

Background:

Commit 1c96127e37c0ec41c7a30ea3e4aa68f3cc8a24f6 standardized the
location where the openafs.ko module is installed (from
/kernel/3rdparty to /extra/).  The RPM Spec file was not updated to
build the dkms.conf file with the corrected location.

From the documentation for dkms

 DEST_MODULE_LOCATION is ignored on Fedora Core 6 and higher, Red Hat
 Enterprise Linux 5 and higher, Novell SuSE Linux Enterprise Server 10
 and higher, Novell SuSE Linux 10.0 and higher, and Ubuntu.  Instead,
 the proper distribution-specific directory is used.

However the DEST_MODULE_LOCATION is still used saving and restoring old
copies of the module.

The NO_WEAK_MODULES parameter prevents dkms from creating a symlink into
weak-updates directory, which can lead to broken symlinks when
dkms-openafs is removed.  The weak modules facility was designed to
eliminate the need to rebuild kernel modules when kernel upgrades occur
and relies on the symbols within the kABI.  Openafs uses symbols that
are outside the kABI, and therefor is not a candidate for a weak module.

Reviewed-on: https://gerrit.openafs.org/13404
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit a28f9d28aef18936eb0ea02491ce64c72eeb1fe9)

Reviewed-on: https://gerrit.openafs.org/13438
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
(cherry picked from commit 53515f40f3dc980cc2c1afd369207617b88e93d1)

Change-Id: I47237bcd40f96d75886207f3cd6f61f15a0e4805
Reviewed-on: https://gerrit.openafs.org/13450
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

14 months agoLinux 4.20: disable -settime support 03/13403/4
Mark Vitale [Fri, 30 Nov 2018 23:13:24 +0000]
Linux 4.20: disable -settime support

In Linux v4.20, do_settimeofday() has been removed in favor of
do_settimeofday64().

This commit is for 1.6.x only.  On master and 1.8.x, -settime support
has been removed from OpenAFS, but on 1.6.x some sites may still be
specifying -settime even though it is deprecated and known to be broken.
Therefore, for 1.6.x we can't simply remove afs_osi_SetTime.  It's also
a waste of time to convert it to use do_settimeofday64() because the
-settime feature is deprecated.

Instead, add an autoconf test to detect the absence of
do_settimeofday().  When do_settimeofday() is missing and -settime has
been specified, log a warning message whenever OpenAFS attempts to
adjust the system time:

   'afs attempted to set clock; use "afsd -nosettime"'

do_settimeofday() was introduced sometime during v2.4.x and thus has
always been present in all Linux versions covered by OpenAFS conditional
AFS_LINUX26_ENV (until now).

We don't need to do anything with the LINUX24 version of
afs_osi_SetTime() since do_settimeofday() will never disappear on those
old Linux versions.

Change-Id: Ia147406e7e2cf42f76466c85b0392a8559bd112b
Reviewed-on: https://gerrit.openafs.org/13403
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

14 months agoLinux 4.20: current_kernel_time is gone 20/13420/3
Mark Vitale [Tue, 13 Nov 2018 16:20:09 +0000]
Linux 4.20: current_kernel_time is gone

With Linux commit 976516404ff3fab2a8caa8bd6f5efc1437fed0b8 'y2038:
remove unused time interfaces' (4.20-rc1), current_kernel_time() has
been removed.

Many y2038-compliant time APIs were introduced with Linux commit
fb7fcc96a86cfaef0f6dcc0665516aa68611e736 'timekeeping: Standardize on
ktime_get_*() naming' (4.18).  According to
Documentation/core-api/timekeeping.rst, a suitable replacement for:

  struct timespec current_kernel_time(void)

would be:

  void ktime_get_coarse_real_ts64(struct timespec64 *ts))

Add an autoconf test and equivalent logic to deal.

Reviewed-on: https://gerrit.openafs.org/13391
Tested-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 3c454b39d04f4886536267c211171dae30dc0344)

Reviewed-on: https://gerrit.openafs.org/13405
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
(cherry picked from commit 7fb6d488156e673e78b462faf93f2c5b2214fe59)

Change-Id: I324fdbadd617f3c8c94e3144e2018ffbb69e4238
Reviewed-on: https://gerrit.openafs.org/13420
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

14 months agoafs: prevent -settime null pointer dereference 01/13401/4
Mark Vitale [Mon, 3 Dec 2018 23:33:29 +0000]
afs: prevent -settime null pointer dereference

If -settime is enabled and afs_setTimeHost is non-NULL, CkSrv_SetTime
will loop over the conns[] array to find a matching connection for the
afs_setTimeHost.  If no match is found, this loop exits with index 'i'
out of bounds for the conns[] array.  We then call
CkSrv_MarkUpDown(&conns[i],..), leading to a null pointer dereference.

Add an additional condition so we only call CkSrv_MarkUpDown() if a
matching conn was found.

Introduced by commit 1219b7617ecfe1d9eb0d7ec22f8e2e714732c51d.

Note:
This is a 1.6.x-specific fix, since -settime support has been removed
from 1.8.x and master.  Despite this fix, afsd -settime remains
deprecated in OpenAFS 1.6.x.

Change-Id: I958a1b563c5777b3c405e0ff77a7b46d2df80426
Reviewed-on: https://gerrit.openafs.org/13401
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

14 months agoafs: Zero settime deltas correctly 06/11706/4
Andrew Deason [Mon, 2 Feb 2015 16:14:02 +0000]
afs: Zero settime deltas correctly

Currently we zero the 'deltas' pointer itself, not the memory we
allocated for it. That's clearly wrong, and should cause a crash
whenever we access 'deltas'. Zero the pointed-to memory instead.

Thanks to Ryan Underwood who pointed out this issue.

This is a 1.6-only commit. On master, the settime code has been
removed entirely.

Change-Id: I0fdea89fb23945246dcbe83b18ec79be0f725fde
Reviewed-on: https://gerrit.openafs.org/11706
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Reviewed-by: Jeffrey Altman <jaltman@auristor.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

14 months agoviced/callback.c: Don't ignore dump read errors 05/13505/2
Jeffrey Hutzelman [Wed, 19 Jun 2013 03:12:46 +0000]
viced/callback.c: Don't ignore dump read errors

When reading a callback state dump, check the return values from
read(2) instead of ignoring them.  This adds a new static function,
ReadBytes(), which handles reading a requested number of bytes from a
file and bailing if there is an error.

Reviewed-on: http://gerrit.openafs.org/9989
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
(cherry picked from commit c854cb31ff2b1ab79de18b5ab926bf2ea2b05663)

Change-Id: Ieffa11c6049eceb23bc6bf9169454529df3ef766
Reviewed-on: https://gerrit.openafs.org/13505
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

14 months agoviced/callback.c: Ignore dump write errors harder 04/13504/2
Jeffrey Hutzelman [Wed, 19 Jun 2013 03:12:46 +0000]
viced/callback.c: Ignore dump write errors harder

When writing a callback state dump, test the return values from
write(2), but don't do anything based on the test.  This avoids
compiler warnings when building on Ubuntu 12.10, with gcc 4.7.2 and
eglibc 2.15-0ubuntu20.1.  This adds a new macro, WriteBytes(), which
handles writing a requested number of bytes to a file and ignoring
errors.

Reviewed-on: http://gerrit.openafs.org/9991
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
(cherry picked from commit e16bef6136f83d0fc9a691051fc54a2ae5f573c9)

Change-Id: Ib88d8354f68f26fb001e3b650791236e42789f31
Reviewed-on: https://gerrit.openafs.org/13504
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>

14 months agovenus: fix format overflow warning 99/13499/2
Michael Meffie [Mon, 19 Feb 2018 19:01:56 +0000]
venus: fix format overflow warning

Recent versions of gcc generate a format overflow warning on the dfstring
buffer in fs.c.  Increase the size of the buffer to avoid a possible buffer
overflow.

    fs.c: In function ‘AclToString’:
    fs.c:770:30: error: ‘%s’ directive writing up to 1024 bytes
    into a region of size between 13 and 23 [-Werror=format-overflow=]
      sprintf(dfsstring, " dfs:%d %s", acl->dfs, acl->cell);
                                  ^~
    fs.c:770:2: note: ‘sprintf’ output between 8 and 1042 bytes into
    a destination of size 30
      sprintf(dfsstring, " dfs:%d %s", acl->dfs, acl->cell);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Reviewed-on: https://gerrit.openafs.org/12917
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit c84f36a9b8c6b6adb9c77bab1c814ccd3aaf6a5b)

Reviewed-on: https://gerrit.openafs.org/13099
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit e1b71e88452b2a5ff7473514661cb85dfac1b3c1)

Change-Id: I332d283c787f35b0d5d72e1c9e8de1145e177719
Reviewed-on: https://gerrit.openafs.org/13499
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>

14 months agobutc: fix format overflow warning 98/13498/2
Michael Meffie [Mon, 19 Feb 2018 18:57:16 +0000]
butc: fix format overflow warning

Recent versions of gcc generate an overflow warning in the butc DUMPNAME macro
when copying values into the finishedMsg1 buffer. Increase the size of the
destination buffer to avoid a possible buffer overflow.

    dump.c:88:24: error: ‘%s’ directive writing up to 63 bytes into
    a region of size 50 [-Werror=format-overflow=]
          sprintf(dumpname, "%s (DumpId %u)", name, dbDumpId);
                            ^
    dump.c:1294:5: note: in expansion of macro ‘DUMPNAME’
         DUMPNAME(finishedMsg1, nodePtr->dumpSetName, dparams.databaseDumpId);
         ^~~~~~~~
    dump.c:88:6: note: ‘sprintf’ output between 12 and 84 bytes into
    a destination of size 50
          sprintf(dumpname, "%s (DumpId %u)", name, dbDumpId);
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    dump.c:1294:5: note: in expansion of macro ‘DUMPNAME’
         DUMPNAME(finishedMsg1, nodePtr->dumpSetName, dparams.databaseDumpId);
         ^~~~~~~~

Reviewed-on: https://gerrit.openafs.org/12916
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit cec45d59440f55316097cfd6652d2ea26cd55233)

Reviewed-on: https://gerrit.openafs.org/13097
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit dba69c2a190103d1941ca6232d9a466f259a206c)

Change-Id: Idb1bc17619018073d14f6047cad404283898a005
Reviewed-on: https://gerrit.openafs.org/13498
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>

14 months agovol: Fix two buffers being one char too short 97/13497/2
Anders Kaseorg [Sat, 2 Sep 2017 03:37:07 +0000]
vol: Fix two buffers being one char too short

Fixes these warnings:

namei_ops.c: In function 'namei_copy_on_write':
namei_ops.c:1328:31: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=]
  snprintf(path, sizeof(path), "%s-tmp", name.n_path);
                               ^~~~~~~~
namei_ops.c:1328:2: note: 'snprintf' output between 5 and 260 bytes into a destination of size 259
  snprintf(path, sizeof(path), "%s-tmp", name.n_path);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

vol_split.c: In function 'split_volume':
vol_split.c:576:22: warning: 'sprintf' may write a terminating nul past the end of the destination [-Wformat-overflow=]
     sprintf(symlink, "#%s", V_name(newvol));
                      ^~~~~
vol_split.c:576:5: note: 'sprintf' output between 2 and 33 bytes into a destination of size 32
     sprintf(symlink, "#%s", V_name(newvol));
     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Reviewed-on: https://gerrit.openafs.org/12722
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 0a9a6b57ce6e1c97fcc651c8cb74e66fc8422a1e)

Reviewed-on: https://gerrit.openafs.org/12723
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 688b3570867cda3035ec6bcd9c7538cf651f38f6)

Change-Id: I44c8e8e8a8049da4b8a1f4c2cfe6c7245661b7b7
Reviewed-on: https://gerrit.openafs.org/13497
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>

14 months agoAvoid format truncation warnings 96/13496/2
Andrew Deason [Tue, 7 Aug 2018 22:27:24 +0000]
Avoid format truncation warnings

With gcc 7.3, we start getting several warnings like the following:

vutil.c: In function ‘VWalkVolumeHeaders’:
vutil.c:860:34: error: ‘%s’ directive output may be truncated writing up to 255 bytes into a region of size 63 [-Werror=format-truncation=]
      snprintf(name, VMAXPATHLEN, "%s" OS_DIRSEP "%s", partpath, dentry->d_name);

Most or all of these truncations should be okay, but increase the size
of the relevant buffers so we can build with warning checking turned
on.

Reviewed-on: https://gerrit.openafs.org/13274
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 2daa413e3ec061e0653adbd1d6549f15e0659a62)

Reviewed-on: https://gerrit.openafs.org/13459
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
(cherry picked from commit 232bd12b070e1fbeb173e31251e65e63a0d1f959)

Change-Id: I64e489cb1b349fc89a304cd8ef2fa68730e29512
Reviewed-on: https://gerrit.openafs.org/13496
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>

14 months agoImport of code from heimdal 95/13495/2
Heimdal Developers [Mon, 2 Jul 2012 14:00:30 +0000]
Import of code from heimdal

This commit updates the code imported from heimdal to
3fe55728404c602884f16126e9cc60fc5a3d8f20 (switch-from-svn-to-git-2993-g3fe5572)

[This commit has been backported to OpenAFS 1.6.x branch, which imports
only krb5/config_file.c]

Reviewed-on: http://gerrit.openafs.org/7612
Tested-by: Jeffrey Altman <jaltman@your-file-system.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
(cherry picked from commit 9c0b7be87de83493ca1d5a01326982ce5c8c131b)

Change-Id: I99d0b15168d6309ee04ac0f7d2bde27c21ba4382
Reviewed-on: https://gerrit.openafs.org/13495
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>

16 months agoCellServDB update 14 May 2018 18/13418/2
Benjamin Kaduk [Thu, 31 May 2018 00:38:57 +0000]
CellServDB update 14 May 2018

Update all three copies in the tree, and the rpm specfile.

Reviewed-on: https://gerrit.openafs.org/13134
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 4a2b5101afda24b2d937e7350ca35b0b3d3c4af8)

Reviewed-on: https://gerrit.openafs.org/13409
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
(cherry picked from commit eca7ade855e0f9b14d0bb763be2d2d3e925dcd86)

[stephan.wiesand@desy.de: added fourth instance still present on 1.6.x]

Change-Id: Ie06fb1f36f60fe1a60342431130d13d66ede8aff
Reviewed-on: https://gerrit.openafs.org/13418
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

20 months agoMerge tag 'openafs-stable-1_6_23' into openafs-stable-1_6_x
Benjamin Kaduk [Fri, 14 Sep 2018 13:09:54 +0000]
Merge tag 'openafs-stable-1_6_23' into openafs-stable-1_6_x

Join the history of the security release into the
1.6.x stable release branch.

Change-Id: I9de0a04c89b079b205475eed93ac8e4a7f46797b

20 months agoMake OpenAFS 1.6.23 openafs-stable-1_6_23
Benjamin Kaduk [Tue, 11 Sep 2018 01:36:31 +0000]
Make OpenAFS 1.6.23

Update version strings for the 1.6.23 release.

Change-Id: I4cbfcca4f986cd201ec3e45d61c7ad53990aede8

20 months agoUpdate NEWS for 1.6.23
Benjamin Kaduk [Tue, 11 Sep 2018 01:26:20 +0000]
Update NEWS for 1.6.23

Release notes for the OpenAFS 1.6.23 security release.

Change-Id: I7c3422ca50f1a6d4f91852d31b91673c65ac95d6

20 months agoFix typos in audit format strings
Benjamin Kaduk [Tue, 11 Sep 2018 15:51:01 +0000]
Fix typos in audit format strings

Commit 9ebff4c6caa8b499d999cfd515d4d45eb3179769 introduced audit
framework support for several butc-related data types, but had
a typo ('$d' for '%d') in a couple of places, that was not reported
by compiler format-string checking.  Fix the typo to properly print
all the auditable data.

(cherry picked from commit d5816fd6cd1876760a985a817dbbb3940cf3bddb)

(cherry picked from commit 90601818205aeefd1cf99b8766a7bfd03bf9b96a)

(cherry picked from commit 0cdb370f1813158a6dbd577e5c250bc26ac4590c)

Change-Id: I0d1cb15d02225a8557da09ed72efbc5103e1ec1b

20 months agoFix typos in audit format strings
Benjamin Kaduk [Tue, 11 Sep 2018 15:51:01 +0000]
Fix typos in audit format strings

Commit 9ebff4c6caa8b499d999cfd515d4d45eb3179769 introduced audit
framework support for several butc-related data types, but had
a typo ('$d' for '%d') in a couple of places, that was not reported
by compiler format-string checking.  Fix the typo to properly print
all the auditable data.

(cherry picked from commit d5816fd6cd1876760a985a817dbbb3940cf3bddb)

(cherry picked from commit 90601818205aeefd1cf99b8766a7bfd03bf9b96a)

Change-Id: I49a8fff424e0a8cc7bdcdcca2878e614d6e70f20

20 months agoOPENAFS-SA-2018-001 backup: use authenticated connection to butc
Benjamin Kaduk [Sun, 9 Sep 2018 15:44:38 +0000]
OPENAFS-SA-2018-001 backup: use authenticated connection to butc

Use the standard routine to pick a client security object, instead of
always assuming rxnull.  Respect -localauth as well as being able to
use the current user's tokens, but also provide a -nobutcauth argument
to fall back to the historical rxnull behavior (but only for the connections
to butc; vldb and budb connections are not affected).

(cherry picked from commit 345ee34236c08a0a2fb3fff016edfa18c7af4b0a)

(cherry picked from commit ed217df4b23e111d4b12e7236bdf6f8ab5575952)

(cherry picked from commit 3f06dd4f73f7fa1f6ecbd71e9ebe2ef5c67dfebd)

20 months agoOPENAFS-SA-2018-001 backup: use authenticated connection to butc
Benjamin Kaduk [Sun, 9 Sep 2018 15:44:38 +0000]
OPENAFS-SA-2018-001 backup: use authenticated connection to butc

Use the standard routine to pick a client security object, instead of
always assuming rxnull.  Respect -localauth as well as being able to
use the current user's tokens, but also provide a -nobutcauth argument
to fall back to the historical rxnull behavior (but only for the connections
to butc; vldb and budb connections are not affected).

(cherry picked from commit 345ee34236c08a0a2fb3fff016edfa18c7af4b0a)

(cherry picked from commit ed217df4b23e111d4b12e7236bdf6f8ab5575952)

20 months agoOPENAFS-SA-2018-001 butc: require authenticated connections with -localauth
Benjamin Kaduk [Thu, 6 Sep 2018 23:50:39 +0000]
OPENAFS-SA-2018-001 butc: require authenticated connections with -localauth

The butc -localauth option is available to use the cell-wide key to
authenticate to the vlserver and buserver, which in normal deployments
will require incoming connections to be authenticated as a superuser.
In such cases, the cell-wide key is also available for use in
authenticating incoming connections to the butc, which would otherwise
have been completely unauthenticated.

Because of the security hazards of allowing unauthenticaed inbound
RPCs, especially ones that manipulate backup information and are allowed
to initiate outboud RPCs authenticated as the superuser, default to
not allowing unauthenticated inbound RPCs at all.  Provide an opt-out
command-line argument for deployments that require this functionality
and have configured their network environment (firewall/etc.) appropriately.

(cherry picked from commit 1b199eeafad6420982380ce5e858f00c528cfd13)

(cherry picked from commit fa04588907321e8b50b64f30dcc049e60268a05a)

Change-Id: Ib796fd4d61cc5d2e98f1b1e787f3267456b0ffe8

20 months agoOPENAFS-SA-2018-001 Add auditing to butc server RPC implementations
Benjamin Kaduk [Sun, 9 Sep 2018 16:49:03 +0000]
OPENAFS-SA-2018-001 Add auditing to butc server RPC implementations

Make the actual implementations into helper functions, with the RPC
stubs calling the helpers and doing the auditing on the results, akin
to most other server programs in the tree.  This relies on support for
some additional types having been added to the audit framework.

(cherry picked from commit c43169fd36348783b1a5a55c5bb05317e86eef82)

(cherry picked from commit 6f8c0c8134de1b5358ec56878e350aeab31aa3cd)

(cherry picked from commit 23f3f2e0d96e30a7bc9c355414db995df820e5ba)

Change-Id: Icb4a9ca3cce81b088268655a648823f3e8260f0a

20 months agoOPENAFS-SA-2018-001 audit: support butc types
Benjamin Kaduk [Sun, 9 Sep 2018 00:42:36 +0000]
OPENAFS-SA-2018-001 audit: support butc types

Add support for several complex butc types to enable butc auditing.

(cherry picked from commit 41d2dd569a365465ac47da3cd39eceba4beaeaf3)

(cherry picked from commit 049b7eafe125d12803e848f38f18680dff31ab80)

Change-Id: I6662f028e300afaa5e2586db1a590f9ea8ec3139

20 months agoOPENAFS-SA-2018-001 butc: remove dummy osi_audit() routine
Benjamin Kaduk [Sun, 9 Sep 2018 01:35:25 +0000]
OPENAFS-SA-2018-001 butc: remove dummy osi_audit() routine

This local stub was present in the original IBM import and is unused.
It will conflict with the real audit code once we start adding auditing
to the TC_ RPCs, so remove it now.

(cherry picked from commit 50216dbbc30ed94f89bdd0e964f4891e87f28c0b)

(cherry picked from commit 7eb650a6edd96e3c7e68f170945ddcdac8b67975)

(cherry picked from commit cf69365f0416c58462cbea75dc17cde01f343175)

Change-Id: Idf9d3dfa040cdd34437d1c97ce27a1225a356993

20 months agoOPENAFS-SA-2018-003 rxgen: prevent unbounded input arrays
Mark Vitale [Fri, 6 Jul 2018 07:14:19 +0000]
OPENAFS-SA-2018-003 rxgen: prevent unbounded input arrays

RPCs with unbounded arrays as inputs are susceptible to remote
denial-of-service (DOS) attacks.  A malicious client may submit an RPC
request with an arbitrarily large array, forcing the server to expend
large amounts of network bandwidth, cpu cycles, and heap memory to
unmarshal the input.

Instead, issue an error message and stop rxgen when it detects an RPC
defined with an unbounded input array.  Thus we will detect the problem
at build time and prevent any future unbounded input arrays.

(cherry picked from commit a4c1d5c48deca2ebf78b1c90310b6d56b3d48af6)

(cherry picked from commit 2cf5cfa8561047e855fed9ab35d1a041e309e39a)

(cherry picked from commit 289a5643e7af399b3e99eb33d50b6c602e442a02)

Change-Id: If5222aab9ce700ba8d9520e5e2e81e66e1b87fd1

20 months agoOPENAFS-SA-2018-003 volser: prevent unbounded input to various AFSVol* RPCs
Mark Vitale [Fri, 6 Jul 2018 07:21:26 +0000]
OPENAFS-SA-2018-003 volser: prevent unbounded input to various AFSVol* RPCs

Several AFSVol* RPCs are defined with an unbounded XDR "string" as
input.

RPCs with unbounded arrays as inputs are susceptible to remote
denial-of-service (DOS) attacks.  A malicious client may submit an
AFSVol* request with an arbitrarily large string, forcing the volserver
to expend large amounts of network bandwidth, cpu cycles, and heap
memory to unmarshal the input.

Instead, give each input "string" an appropriate size.
Volume names are inherently capped to 32 octets (including trailing NUL)
by the protocol, but there is less clearly a hard limit on partition names.
The Vol_PartitionInfo{,64} functions accept a partition name as input and
also return a partition name in the output structure; the output values
have wire-protocol limits, so larger values could not be retrieved by clients,
but for denial-of-service purposes, a more generic PATH_MAX-like value seems
appropriate.  We have several varying sources of such a limit in the tree, but
pick 4k as the least-restrictive.

[kaduk@mit.edu: use a larger limit for pathnames and expand on PATH_MAX in
commit message]

(cherry picked from commit 8b92d015ccdfcb70c7acfc38e330a0475a1fbe28)

(cherry picked from commit fe41fa565be6e325da75f3e9b8fbdac2c521b027)

(cherry picked from commit 39b675e243be70237ba9460b49b461c128aedffd)

Change-Id: Idad0b0abf582b356042245398e1317a610ff321e

20 months agoOPENAFS-SA-2018-003 volser: prevent unbounded input to AFSVolForwardMultiple
Mark Vitale [Fri, 6 Jul 2018 05:09:53 +0000]
OPENAFS-SA-2018-003 volser: prevent unbounded input to AFSVolForwardMultiple

AFSVolForwardMultiple is defined with an input parameter that is defined
to XDR as an unbounded array of replica structs:
  typedef replica manyDests<>;

RPCs with unbounded arrays as inputs are susceptible to remote
denial-of-service (DOS) attacks.  A malicious client may submit an
AFSVolForwardMultiple request with an arbitrarily large array, forcing
the volserver to expend large amounts of network bandwidth, cpu cycles,
and heap memory to unmarshal the input.

Even though AFSVolForwardMultiple requires superuser authorization, this
attack is exploitable by non-authorized actors because XDR unmarshalling
happens long before any authorization checks can occur.

Add a bounding constant (NMAXNSERVERS 13) to the manyDests input array.
This constant is derived from the current OpenAFS vldb implementation, which
is limited to 13 replica sites for a given volume by the layout (size) of the
serverNumber, serverPartition, and serverFlags fields.

[kaduk@mit.edu: explain why this constant is used]

(cherry picked from commit 97b0ee4d9c9d069e78af2e046c7987aa4d3f9844)

(cherry picked from commit fac3749f0d180e0ca229326c0e8568a60e17d3e9)

(cherry picked from commit ea30e64d1b2153f51a83069f3471356553a27a2b)

Change-Id: Ib2e5d4cc660e0a278b9dbd10ac2db656239e1302

20 months agoOPENAFS-SA-2018-003 budb: prevent unbounded input to BUDB_SaveText
Mark Vitale [Fri, 6 Jul 2018 03:51:37 +0000]
OPENAFS-SA-2018-003 budb: prevent unbounded input to BUDB_SaveText

BUDB_SaveText is defined with an input parameter that is defined to XDR
as an unbounded array of chars:
   typedef char charListT<>;

RPCs with unbounded arrays as inputs are susceptible to remote
denial-of-service (DOS) attacks.  A malicious client may submit a
BUDB_SaveText request with an arbitrarily large array, forcing the budb
server to expend large amounts of network bandwidth, cpu cycles, and
heap memory to unmarshal the input.

Modify the XDR definition of charListT so it is bounded.  This typedef
is shared (as an OUT parameter) by BUDB_GetText and BUDB_DumpDB, but
fortunately all in-tree callers of the client routines specify the same
maximum length of 1024.

Note: However, SBUDB_SaveText server implementation seems to allow for up to
BLOCK_DATA_SIZE (2040) = BLOCKSIZE (2048) - sizeof(struct blockHeader)
(8), and it's unknown if any out-of-tree callers exist.  Since we do not need a
tight bound in order to avoid the DoS, use a somewhat higher maximum of
4096 bytes to leave a safety margin.

[kaduk@mit.edu: bump the margin to 4096; adjust commit message to match]

(cherry picked from commit 124445c0c47994f5e2efef30e86337c3c8ebc93f)

(cherry picked from commit 87f199c14199afa29f75bb336383564f0fb4548a)

(cherry picked from commit c5c3a858b21eaaabda46e1dffdea038fa234d657)

Change-Id: I6802e76a5f6e39e31ece66d1ff00ed11b47b6c36

20 months agoOPENAFS-SA-2018-003 vlserver: prevent unbounded input to VL_RegisterAddrs
Mark Vitale [Fri, 6 Jul 2018 01:11:30 +0000]
OPENAFS-SA-2018-003 vlserver: prevent unbounded input to VL_RegisterAddrs

VL_RegisterAddrs is defined with an input argument of type bulkaddrs,
which is defined to XDR as an unbounded array of afs_uint32 (IPv4 addresses):
  typedef afs_uint32 bulkaddrs<>

The <> with no value instructs rxgen to build client and server stubs
that allow for a maximum size of "~0u" or 0xFFFFFFFF.

Ostensibly the bulkaddrs array is unbounded to allow it to be shared
among VL_RegisterAddrs, VL_GetAddrs, and VL_GetAddrsU.  The VL_GetAddrs*
RPCs use bulkaddrs as an output array with a maximum size of MAXSERVERID
(254). VL_RegisterAddrss uses bulkaddrs as an input array, with a
nominal size of VL_MAXIPADDRS_PERMH (16).

However, RPCs with unbounded array inputs are susceptible to remote
denial-of-service attacks.  That is, a malicious client may send a
VL_RegisterAddrs request with an arbitrarily long array, forcing the
vlserver to expend large amounts of network bandwidth, cpu cycles, and
heap memory to unmarshal the argument.  Even though VL_RegisterAddrs
requires superuser authorization, this attack is exploitable by
non-authorized actors because XDR unmarshalling happens long before any
authorization checks can occur.

Because all uses of the type that our implementation support have fixed
bounds on valid data (whether input or output), apply an arbitrary
implementation limit (larger than any valid structure would be), to
prevent this class of attacks in the XDR decoder.

[kaduk@mit.edu: limit the bulkaddrs type instead of introducing a new type]

(cherry picked from commit 7629209219bbea3f127b33be06ac427ebc3a559e)

(cherry picked from commit 4218dc0a2db75c740d1d31966e672f85ad7999bd)

(cherry picked from commit 38f401ae7e0e88fb65b651125a2c8a723db1e071)

Change-Id: Ib0798af007af14a2a91ae280c0f28838f33d1a65

20 months agoOPENAFS-SA-2018-002 butc: Initialize OUT scalar value
Benjamin Kaduk [Thu, 30 Aug 2018 15:38:56 +0000]
OPENAFS-SA-2018-002 butc: Initialize OUT scalar value

In STC_ReadLabel, the interaction with the tape device is
synchronous, so there is no need to allocate a task ID for status
monitoring.  However, we do need to initialize the output value,
to avoid writing stack garbage on the wire.

(cherry picked from commit f5a80115f8f7f9418287547f0fc7fdb13d936f00)

(cherry picked from commit 418b2ab56c60e44375df31a3a8f77461d577a5ff)

(cherry picked from commit babbb2824a5e3d6210b9079ab08f8771ac6ef892)

Change-Id: Ie18bbe7542a23d2ce952cfcd5288ee0aa43bb71f

20 months agoOPENAFS-SA-2018-002 ubik: prevent VOTE_Debug, VOTE_XDebug information leak
Mark Vitale [Tue, 26 Jun 2018 10:01:16 +0000]
OPENAFS-SA-2018-002 ubik: prevent VOTE_Debug, VOTE_XDebug information leak

VOTE_Debug and VOTE_XDebug (udebug) both leave a single field
uninitialized if there is no current transaction.  This leaks the memory
contents of the ubik server over the wire.

struct ubik_debug
- 4 bytes in member writeTrans

In common code to both RPCs, ensure that writeTrans is always
initialized.

[kaduk@mit.edu: switch to memset]

(cherry picked from commit 7a7c1f751cdb06c0d95339c999b2c035c2d2168b)

(cherry picked from commit 0ee86cc3f986365df9de21ede5735cc1f40db7e5)

(cherry picked from commit 9db5fcf460988b605ba8ba7078b9c8d702aba370)

Change-Id: I1c9fc9a6a8bb8aed04f814e4da041af3f49a7401

20 months agoOPENAFS-SA-2018-002 kaserver: prevent KAM_ListEntry information leak
Mark Vitale [Tue, 26 Jun 2018 09:26:21 +0000]
OPENAFS-SA-2018-002 kaserver: prevent KAM_ListEntry information leak

KAM_ListEntry (kas list) does not initialize its output correctly.  It
leaks kaserver memory contents over the wire:

struct kaindex
- up to 64 bytes for member name
- up to 64 bytes for member instance

Initialize the buffer.

[kaduk@mit.edu: move initialization to top of server routine]

(cherry picked from commit b604ee7add7be416bf20973422a041e913d20761)

(cherry picked from commit c912830e9c82d91bccf85018ef1e6a75edc410c4)

(cherry picked from commit 04fb009f15b75aca8e62675972ce23526a62ba80)

Change-Id: I613b1f46b913d4208bac15eb92274127da14e9c9

20 months agoOPENAFS-SA-2018-002 butc: prevent TC_DumpStatus, TC_ScanStatus information leaks
Mark Vitale [Tue, 26 Jun 2018 09:12:32 +0000]
OPENAFS-SA-2018-002 butc: prevent TC_DumpStatus, TC_ScanStatus information leaks

TC_ScanStatus (backup status) and TC_GetStatus (internal backup status
watcher) do not initialize their output buffers.  They leak memory
contents over the wire:

struct tciStatusS
- up to 64 bytes in member taskName (TC_MAXNAMELEN 64)
- up to 64 bytes in member volumeName  "

Initialize the buffers.

[kaduk@mit.edu: move initialization to top of server routines]

(cherry picked from commit be0142707ca54f3de99c4886530e7ac9f48dd61c)

(cherry picked from commit 43b3efd4f8cd3227b2b24ff673adeb834f6a3f0b)

(cherry picked from commit a41b75a13b9a96a929fa69db43fbc4ca071ee717)

Change-Id: Ibe35ca06eb663399f0b9e14d7487d91553cd67c8

20 months agoOPENAFS-SA-2018-002 butc: prevent TC_ReadLabel information leak
Mark Vitale [Tue, 26 Jun 2018 09:00:25 +0000]
OPENAFS-SA-2018-002 butc: prevent TC_ReadLabel information leak

TC_ReadLabel (backup readlabel) does not initialize its output buffer
completely.  It leaks butc memory contents over the wire:

struct tc_tapeLabel
- up to 32 bytes from member afsname (TC_MAXTAPELEN 32)
- up to 32 bytes from member pname (TC_MAXTAPELEN 32)

Initialize the buffer.

[kaduk@mit.edu: move initialization to the RPC stub]

(cherry picked from commit 52f4d63148323e7d605f9194ff8c1549756e654b)

(cherry picked from commit b7e53b9e9706d63215a1804ed9eca30d69461f03)

(cherry picked from commit 3e0294543d4f4ab58694e1aca393b961f05d7c8f)

Change-Id: I4e8ab1b94d36e9904a9505cd7f0e97cc6fb3a40f

20 months agoOPENAFS-SA-2018-002 budb: prevent BUDB_* information leaks
Mark Vitale [Tue, 26 Jun 2018 08:39:44 +0000]
OPENAFS-SA-2018-002 budb: prevent BUDB_* information leaks

The following budb RPCs do not initialize their output correctly.
This leaks buserver memory contents over the wire:

BUDB_FindLatestDump (backup dump)
BUDB_FindDump (backup volrestore, diskrestore, volsetrestore)
BUDB_GetDumps (backup dumpinfo)
BUDB_FindLastTape (backup dump)

struct budb_dumpEntry
- up to 32 bytes in member volumeSetName
- up to 256 bytes in member dumpPath
- up to 32 bytes in member name
- up to 32 bytes in member tape.tapeServer
- up to 32 bytes in member tape.format
- up to 256 bytes in member dumper.name
- up to 128 bytes in member dumper.instance
- up to 256 bytes in member dumper.cell

Initialize the buffer in common routine FillDumpEntry.

(cherry picked from commit e96771471134102d3879a0ac8b2c4ef9d91a61b8)

(cherry picked from commit 6f26a945adeca87b669282eed0eaca3dca0a1423)

(cherry picked from commit b4543ae2331fae6d70c067d86d20bfbc8d509468)

Change-Id: I713f967eebc1286764b9658ff4ddccb65f456480

20 months agoOPENAFS-SA-2018-002 afs: prevent RXAFSCB_TellMeAboutYourself information leak
Mark Vitale [Tue, 26 Jun 2018 07:56:24 +0000]
OPENAFS-SA-2018-002 afs: prevent RXAFSCB_TellMeAboutYourself information leak

RXAFSCB_TellMeAboutYourself does not completely initialize its output
buffers.  This leaks kernel memory over the wire:

struct interfaceAddr
Unix cache manager (libafs)
- up to 124 bytes in array addr_in ((AFS_MAX_INTERFACE_ADDR 32 * 4) - 4))
- up to 124 bytes in array subnetmask "
- up to 124 bytes in array mtu "

Windows cache manager
- 64 bytes in array addr_in ((AFS_MAX_INTERFACE_ADDR 32 - CM_MAXINTERFACE_ADDR 16)* 4)
- 64 bytes in array subnetmask "
- 64 bytes in array mtu         "

The following implementations of SRXAFSCB_TellMeAboutYourself are not susceptible:
- fsprobe
- libafscp
- xstat_fs_test

Initialize the buffer.

(cherry picked from commit 211b6d6a4307006da1467b3be46912a3a5d7b20b)

(cherry picked from commit a6557ffa64d8fab3526c4f89629dcbb965a27780)

(cherry picked from commit 0dbbcc9ac62425618a3a3a28ee05eba2507f6efd)

Change-Id: Ic977c8a473df12f64d2865cd68f1f42744b57d9e

20 months agoOPENAFS-SA-2018-002 afs: prevent RXAFSCB_GetLock information leak
Mark Vitale [Tue, 26 Jun 2018 07:47:41 +0000]
OPENAFS-SA-2018-002 afs: prevent RXAFSCB_GetLock information leak

RXAFSCB_GetLock (cmdebug) does not correctly initialize its output.
This leaks kernel memory over the wire:

struct AFSDBLock
- up to 14 bytes for member name (16 - '<cellname>\0')

Initialize the buffer.

(cherry picked from commit b52eb11a08f2ad786238434141987da27b81e743)

(cherry picked from commit 3dea4adaa356b7eed40b6162c106c5e90690f5a1)

(cherry picked from commit f0c4f8d899214bf405e809be813be4d5be125ad8)

Change-Id: I3935968bacb8e063fd1fdd2fc52efd2258a5eb99

20 months agoOPENAFS-SA-2018-002 ptserver: prevent PR_ListEntries information leak
Mark Vitale [Tue, 26 Jun 2018 07:37:37 +0000]
OPENAFS-SA-2018-002 ptserver: prevent PR_ListEntries information leak

PR_ListEntries (pts listentries) does not properly initialize its output
buffers.  This leaks ptserver memory over the wire:

struct prlistentries
- up to 62 bytes for each entry name (PR_MAXNAMELEN 64 - 'a\0')

Initialize the buffer, and remove the now redundant memset for the
reserved fields.

(cherry picked from commit 9d1aeb5d761581a35bef2042e9116b96e9ae3bf5)

(cherry picked from commit e19ad4cdde463d2bbb4b815525da992bd5fc2648)

(cherry picked from commit 7ee25861685a4f56b304627ca2a0dbfed179646d)

Change-Id: I42d32876ddf8fa98744620fdf75b4e0783b93aba

20 months agoOPENAFS-SA-2018-002 volser: prevent AFSVolMonitor information leak
Mark Vitale [Tue, 26 Jun 2018 07:00:02 +0000]
OPENAFS-SA-2018-002 volser: prevent AFSVolMonitor information leak

AFSVolMonitor (vos status) does not properly initialize its output
buffers.  This leaks information from volserver memory:

struct transDebugInfo
- up to 29 bytes in member lastProcName (30-'\0')
- 16 bytes in members readNext, tranmitNext, lastSendTime,
  lastReceiveTime

Initialize the buffers.  This must be done on a per-buffer basis inside
the loop, since realloc is used to expand the storage if needed,
and there is not a standard realloc API to zero the newly allocated storage.

[kaduk@mit.edu: update commit message]

(cherry picked from commit 26924fd508b21bb6145e77dc31b6cd0923193b72)

(cherry picked from commit 2d22756de7af2c72b8aca6969825f8e921f01d6c)

(cherry picked from commit 37cbe68577d39241a2d5a1fe75e8a0490516dfc4)

Change-Id: I1eab9e35207fed5d151c70962c00b6fa8ac7da58

20 months agoOPENAFS-SA-2018-002 volser: prevent AFSVolPartitionInfo(64) information leak
Mark Vitale [Tue, 26 Jun 2018 06:33:05 +0000]
OPENAFS-SA-2018-002 volser: prevent AFSVolPartitionInfo(64) information leak

AFSVolPartitionInfo and AFSVolPartitionInfo64 (vos partinfo) do not
properly initialize their reply buffers.  This leaks the contents of
volserver memory over the wire:

AFSVolPartitionInfo (struct diskPartition)
- up to 24 bytes in member name (32-'/vicepa\0'))
- up to 12 bytes in member devName (32-'/vicepa/Lock/vicepa\0'))

AFSVolPartitionInfo64 (struct diskPartition64)
- up to 248 bytes in member name (256-'/vicepa\0'))
- up to 236 bytes in member devName (256-'/vicepa/Lock/vicepa\0')

Initialize the output buffers.

[kaduk@mit.edu: move memset to top-level function scope of RPC handlers]

(cherry picked from commit 76e62c1de868c2b2e3cc56a35474e15dc4cc1551)

(cherry picked from commit 28edf734db08d3a8285e89d9d78aa21db726e4c7)

(cherry picked from commit f1c9c0160e364b4935fbb758890fcf5dc0edad4a)

Change-Id: I48348b326f0933a0fcb556425f085abad36d3bea

20 months agoOPENAFS-SA-2018-002 ptserver: prevent PR_IDToName information leak
Mark Vitale [Mon, 25 Jun 2018 22:03:12 +0000]
OPENAFS-SA-2018-002 ptserver: prevent PR_IDToName information leak

SPR_IDToName does not completely initialize the return array of names,
and thus leaks information from ptserver memory:

- up to 62 bytes per requested id (PR_MAXNAMELEN 64 - 'a\0')

Use calloc to ensure that all memory sent on the wire is initialized,
preventing the information leak.

[kaduk@mit.edu: switch to calloc; update commit message]

(cherry picked from commit 70b0136d552a0077d3fae68f3aebacd985abd522)

(cherry picked from commit c8c8682bb0e84ee5289fac3063119ae524773f61)

(cherry picked from commit 40343287fbca6f4b1098f5b60ef9ff5416376b08)

Change-Id: I793ccc2f3595344e72e9b4ba948a2266f1c4c0a5

20 months agoOPENAFS-SA-2018-001 butc: require authenticated connections with -localauth
Benjamin Kaduk [Thu, 6 Sep 2018 23:50:39 +0000]
OPENAFS-SA-2018-001 butc: require authenticated connections with -localauth

The butc -localauth option is available to use the cell-wide key to
authenticate to the vlserver and buserver, which in normal deployments
will require incoming connections to be authenticated as a superuser.
In such cases, the cell-wide key is also available for use in
authenticating incoming connections to the butc, which would otherwise
have been completely unauthenticated.

Because of the security hazards of allowing unauthenticaed inbound
RPCs, especially ones that manipulate backup information and are allowed
to initiate outboud RPCs authenticated as the superuser, default to
not allowing unauthenticated inbound RPCs at all.  Provide an opt-out
command-line argument for deployments that require this functionality
and have configured their network environment (firewall/etc.) appropriately.

(cherry picked from commit 1b199eeafad6420982380ce5e858f00c528cfd13)

Change-Id: I914f867bf3a328de0e994f999b5e106a6efe71b5

20 months agoOPENAFS-SA-2018-001 Add auditing to butc server RPC implementations
Benjamin Kaduk [Sun, 9 Sep 2018 16:49:03 +0000]
OPENAFS-SA-2018-001 Add auditing to butc server RPC implementations

Make the actual implementations into helper functions, with the RPC
stubs calling the helpers and doing the auditing on the results, akin
to most other server programs in the tree.  This relies on support for
some additional types having been added to the audit framework.

(cherry picked from commit c43169fd36348783b1a5a55c5bb05317e86eef82)

(cherry picked from commit 6f8c0c8134de1b5358ec56878e350aeab31aa3cd)

Change-Id: I7535b60d730975ab9ebbb4a8cb7de45fca29c985

20 months agoOPENAFS-SA-2018-001 audit: support butc types
Benjamin Kaduk [Sun, 9 Sep 2018 00:42:36 +0000]
OPENAFS-SA-2018-001 audit: support butc types

Add support for several complex butc types to enable butc auditing.

(cherry picked from commit 41d2dd569a365465ac47da3cd39eceba4beaeaf3)

Change-Id: Ib26984b614d4a44d9baa33552c0b7d3de736c97d

20 months agoOPENAFS-SA-2018-001 butc: remove dummy osi_audit() routine
Benjamin Kaduk [Sun, 9 Sep 2018 01:35:25 +0000]
OPENAFS-SA-2018-001 butc: remove dummy osi_audit() routine

This local stub was present in the original IBM import and is unused.
It will conflict with the real audit code once we start adding auditing
to the TC_ RPCs, so remove it now.

(cherry picked from commit 50216dbbc30ed94f89bdd0e964f4891e87f28c0b)

(cherry picked from commit 7eb650a6edd96e3c7e68f170945ddcdac8b67975)

Change-Id: I87e7df4ff40d3a233de9df4c7edad8e9d35aebf4

20 months agoOPENAFS-SA-2018-003 rxgen: prevent unbounded input arrays
Mark Vitale [Fri, 6 Jul 2018 07:14:19 +0000]
OPENAFS-SA-2018-003 rxgen: prevent unbounded input arrays

RPCs with unbounded arrays as inputs are susceptible to remote
denial-of-service (DOS) attacks.  A malicious client may submit an RPC
request with an arbitrarily large array, forcing the server to expend
large amounts of network bandwidth, cpu cycles, and heap memory to
unmarshal the input.

Instead, issue an error message and stop rxgen when it detects an RPC
defined with an unbounded input array.  Thus we will detect the problem
at build time and prevent any future unbounded input arrays.

(cherry picked from commit a4c1d5c48deca2ebf78b1c90310b6d56b3d48af6)

(cherry picked from commit 2cf5cfa8561047e855fed9ab35d1a041e309e39a)

Change-Id: I6b740d0ad75ac8a6c8333cf164220691a04c144b

20 months agoOPENAFS-SA-2018-003 volser: prevent unbounded input to various AFSVol* RPCs
Mark Vitale [Fri, 6 Jul 2018 07:21:26 +0000]
OPENAFS-SA-2018-003 volser: prevent unbounded input to various AFSVol* RPCs

Several AFSVol* RPCs are defined with an unbounded XDR "string" as
input.

RPCs with unbounded arrays as inputs are susceptible to remote
denial-of-service (DOS) attacks.  A malicious client may submit an
AFSVol* request with an arbitrarily large string, forcing the volserver
to expend large amounts of network bandwidth, cpu cycles, and heap
memory to unmarshal the input.

Instead, give each input "string" an appropriate size.
Volume names are inherently capped to 32 octets (including trailing NUL)
by the protocol, but there is less clearly a hard limit on partition names.
The Vol_PartitionInfo{,64} functions accept a partition name as input and
also return a partition name in the output structure; the output values
have wire-protocol limits, so larger values could not be retrieved by clients,
but for denial-of-service purposes, a more generic PATH_MAX-like value seems
appropriate.  We have several varying sources of such a limit in the tree, but
pick 4k as the least-restrictive.

[kaduk@mit.edu: use a larger limit for pathnames and expand on PATH_MAX in
commit message]

(cherry picked from commit 8b92d015ccdfcb70c7acfc38e330a0475a1fbe28)

(cherry picked from commit fe41fa565be6e325da75f3e9b8fbdac2c521b027)

Change-Id: I0ba32b30d260e0e1f66cad0f383441a446f7b7bc

20 months agoOPENAFS-SA-2018-003 volser: prevent unbounded input to AFSVolForwardMultiple
Mark Vitale [Fri, 6 Jul 2018 05:09:53 +0000]
OPENAFS-SA-2018-003 volser: prevent unbounded input to AFSVolForwardMultiple

AFSVolForwardMultiple is defined with an input parameter that is defined
to XDR as an unbounded array of replica structs:
  typedef replica manyDests<>;

RPCs with unbounded arrays as inputs are susceptible to remote
denial-of-service (DOS) attacks.  A malicious client may submit an
AFSVolForwardMultiple request with an arbitrarily large array, forcing
the volserver to expend large amounts of network bandwidth, cpu cycles,
and heap memory to unmarshal the input.

Even though AFSVolForwardMultiple requires superuser authorization, this
attack is exploitable by non-authorized actors because XDR unmarshalling
happens long before any authorization checks can occur.

Add a bounding constant (NMAXNSERVERS 13) to the manyDests input array.
This constant is derived from the current OpenAFS vldb implementation, which
is limited to 13 replica sites for a given volume by the layout (size) of the
serverNumber, serverPartition, and serverFlags fields.

[kaduk@mit.edu: explain why this constant is used]

(cherry picked from commit 97b0ee4d9c9d069e78af2e046c7987aa4d3f9844)

(cherry picked from commit fac3749f0d180e0ca229326c0e8568a60e17d3e9)

Change-Id: I57a0aa15b5a92a111f835b7a58f7495376e3e63b

20 months agoOPENAFS-SA-2018-003 budb: prevent unbounded input to BUDB_SaveText
Mark Vitale [Fri, 6 Jul 2018 03:51:37 +0000]
OPENAFS-SA-2018-003 budb: prevent unbounded input to BUDB_SaveText

BUDB_SaveText is defined with an input parameter that is defined to XDR
as an unbounded array of chars:
   typedef char charListT<>;

RPCs with unbounded arrays as inputs are susceptible to remote
denial-of-service (DOS) attacks.  A malicious client may submit a
BUDB_SaveText request with an arbitrarily large array, forcing the budb
server to expend large amounts of network bandwidth, cpu cycles, and
heap memory to unmarshal the input.

Modify the XDR definition of charListT so it is bounded.  This typedef
is shared (as an OUT parameter) by BUDB_GetText and BUDB_DumpDB, but
fortunately all in-tree callers of the client routines specify the same
maximum length of 1024.

Note: However, SBUDB_SaveText server implementation seems to allow for up to
BLOCK_DATA_SIZE (2040) = BLOCKSIZE (2048) - sizeof(struct blockHeader)
(8), and it's unknown if any out-of-tree callers exist.  Since we do not need a
tight bound in order to avoid the DoS, use a somewhat higher maximum of
4096 bytes to leave a safety margin.

[kaduk@mit.edu: bump the margin to 4096; adjust commit message to match]

(cherry picked from commit 124445c0c47994f5e2efef30e86337c3c8ebc93f)

(cherry picked from commit 87f199c14199afa29f75bb336383564f0fb4548a)

Change-Id: If62f472932f08b6211f829a4b2bfbeb85585886b

20 months agoOPENAFS-SA-2018-003 vlserver: prevent unbounded input to VL_RegisterAddrs
Mark Vitale [Fri, 6 Jul 2018 01:11:30 +0000]
OPENAFS-SA-2018-003 vlserver: prevent unbounded input to VL_RegisterAddrs

VL_RegisterAddrs is defined with an input argument of type bulkaddrs,
which is defined to XDR as an unbounded array of afs_uint32 (IPv4 addresses):
  typedef afs_uint32 bulkaddrs<>

The <> with no value instructs rxgen to build client and server stubs
that allow for a maximum size of "~0u" or 0xFFFFFFFF.

Ostensibly the bulkaddrs array is unbounded to allow it to be shared
among VL_RegisterAddrs, VL_GetAddrs, and VL_GetAddrsU.  The VL_GetAddrs*
RPCs use bulkaddrs as an output array with a maximum size of MAXSERVERID
(254). VL_RegisterAddrss uses bulkaddrs as an input array, with a
nominal size of VL_MAXIPADDRS_PERMH (16).

However, RPCs with unbounded array inputs are susceptible to remote
denial-of-service attacks.  That is, a malicious client may send a
VL_RegisterAddrs request with an arbitrarily long array, forcing the
vlserver to expend large amounts of network bandwidth, cpu cycles, and
heap memory to unmarshal the argument.  Even though VL_RegisterAddrs
requires superuser authorization, this attack is exploitable by
non-authorized actors because XDR unmarshalling happens long before any
authorization checks can occur.

Because all uses of the type that our implementation support have fixed
bounds on valid data (whether input or output), apply an arbitrary
implementation limit (larger than any valid structure would be), to
prevent this class of attacks in the XDR decoder.

[kaduk@mit.edu: limit the bulkaddrs type instead of introducing a new type]

(cherry picked from commit 7629209219bbea3f127b33be06ac427ebc3a559e)

(cherry picked from commit 4218dc0a2db75c740d1d31966e672f85ad7999bd)

Change-Id: Ic3112ebe13cf3550dce03537670896457e00b3b9

20 months agoOPENAFS-SA-2018-002 butc: Initialize OUT scalar value
Benjamin Kaduk [Thu, 30 Aug 2018 15:38:56 +0000]
OPENAFS-SA-2018-002 butc: Initialize OUT scalar value

In STC_ReadLabel, the interaction with the tape device is
synchronous, so there is no need to allocate a task ID for status
monitoring.  However, we do need to initialize the output value,
to avoid writing stack garbage on the wire.

(cherry picked from commit f5a80115f8f7f9418287547f0fc7fdb13d936f00)

(cherry picked from commit 418b2ab56c60e44375df31a3a8f77461d577a5ff)

Change-Id: Iaf89d857734bc05a06ebdbd86074b5eadbf100dd

20 months agoOPENAFS-SA-2018-002 ubik: prevent VOTE_Debug, VOTE_XDebug information leak
Mark Vitale [Tue, 26 Jun 2018 10:01:16 +0000]
OPENAFS-SA-2018-002 ubik: prevent VOTE_Debug, VOTE_XDebug information leak

VOTE_Debug and VOTE_XDebug (udebug) both leave a single field
uninitialized if there is no current transaction.  This leaks the memory
contents of the ubik server over the wire.

struct ubik_debug
- 4 bytes in member writeTrans

In common code to both RPCs, ensure that writeTrans is always
initialized.

[kaduk@mit.edu: switch to memset]

(cherry picked from commit 7a7c1f751cdb06c0d95339c999b2c035c2d2168b)

(cherry picked from commit 0ee86cc3f986365df9de21ede5735cc1f40db7e5)

Change-Id: I7fcde3970e6c6d46c8ac1caecd76fa9cb832807c

20 months agoOPENAFS-SA-2018-002 kaserver: prevent KAM_ListEntry information leak
Mark Vitale [Tue, 26 Jun 2018 09:26:21 +0000]
OPENAFS-SA-2018-002 kaserver: prevent KAM_ListEntry information leak

KAM_ListEntry (kas list) does not initialize its output correctly.  It
leaks kaserver memory contents over the wire:

struct kaindex
- up to 64 bytes for member name
- up to 64 bytes for member instance

Initialize the buffer.

[kaduk@mit.edu: move initialization to top of server routine]

(cherry picked from commit b604ee7add7be416bf20973422a041e913d20761)

(cherry picked from commit c912830e9c82d91bccf85018ef1e6a75edc410c4)

Change-Id: I51229a121cbc4e428169635e8fc46321fb52b813

20 months agoOPENAFS-SA-2018-002 butc: prevent TC_DumpStatus, TC_ScanStatus information leaks
Mark Vitale [Tue, 26 Jun 2018 09:12:32 +0000]
OPENAFS-SA-2018-002 butc: prevent TC_DumpStatus, TC_ScanStatus information leaks

TC_ScanStatus (backup status) and TC_GetStatus (internal backup status
watcher) do not initialize their output buffers.  They leak memory
contents over the wire:

struct tciStatusS
- up to 64 bytes in member taskName (TC_MAXNAMELEN 64)
- up to 64 bytes in member volumeName  "

Initialize the buffers.

[kaduk@mit.edu: move initialization to top of server routines]

(cherry picked from commit be0142707ca54f3de99c4886530e7ac9f48dd61c)

(cherry picked from commit 43b3efd4f8cd3227b2b24ff673adeb834f6a3f0b)

Change-Id: I03ebbf76a9e22d15b774e04deb0f2750625c3646

20 months agoOPENAFS-SA-2018-002 butc: prevent TC_ReadLabel information leak
Mark Vitale [Tue, 26 Jun 2018 09:00:25 +0000]
OPENAFS-SA-2018-002 butc: prevent TC_ReadLabel information leak

TC_ReadLabel (backup readlabel) does not initialize its output buffer
completely.  It leaks butc memory contents over the wire:

struct tc_tapeLabel
- up to 32 bytes from member afsname (TC_MAXTAPELEN 32)
- up to 32 bytes from member pname (TC_MAXTAPELEN 32)

Initialize the buffer.

[kaduk@mit.edu: move initialization to the RPC stub]

(cherry picked from commit 52f4d63148323e7d605f9194ff8c1549756e654b)

(cherry picked from commit b7e53b9e9706d63215a1804ed9eca30d69461f03)

Change-Id: I606fcf5afdb176cb4a2ca7bff0a56761b7ae2d48

20 months agoOPENAFS-SA-2018-002 budb: prevent BUDB_* information leaks
Mark Vitale [Tue, 26 Jun 2018 08:39:44 +0000]
OPENAFS-SA-2018-002 budb: prevent BUDB_* information leaks

The following budb RPCs do not initialize their output correctly.
This leaks buserver memory contents over the wire:

BUDB_FindLatestDump (backup dump)
BUDB_FindDump (backup volrestore, diskrestore, volsetrestore)
BUDB_GetDumps (backup dumpinfo)
BUDB_FindLastTape (backup dump)

struct budb_dumpEntry
- up to 32 bytes in member volumeSetName
- up to 256 bytes in member dumpPath
- up to 32 bytes in member name
- up to 32 bytes in member tape.tapeServer
- up to 32 bytes in member tape.format
- up to 256 bytes in member dumper.name
- up to 128 bytes in member dumper.instance
- up to 256 bytes in member dumper.cell

Initialize the buffer in common routine FillDumpEntry.

(cherry picked from commit e96771471134102d3879a0ac8b2c4ef9d91a61b8)

(cherry picked from commit 6f26a945adeca87b669282eed0eaca3dca0a1423)

Change-Id: I4abe5759ae0c0b22af46b640e19a808db7b556a2

20 months agoOPENAFS-SA-2018-002 afs: prevent RXAFSCB_TellMeAboutYourself information leak
Mark Vitale [Tue, 26 Jun 2018 07:56:24 +0000]
OPENAFS-SA-2018-002 afs: prevent RXAFSCB_TellMeAboutYourself information leak

RXAFSCB_TellMeAboutYourself does not completely initialize its output
buffers.  This leaks kernel memory over the wire:

struct interfaceAddr
Unix cache manager (libafs)
- up to 124 bytes in array addr_in ((AFS_MAX_INTERFACE_ADDR 32 * 4) - 4))
- up to 124 bytes in array subnetmask "
- up to 124 bytes in array mtu "

Windows cache manager
- 64 bytes in array addr_in ((AFS_MAX_INTERFACE_ADDR 32 - CM_MAXINTERFACE_ADDR 16)* 4)
- 64 bytes in array subnetmask "
- 64 bytes in array mtu         "

The following implementations of SRXAFSCB_TellMeAboutYourself are not susceptible:
- fsprobe
- libafscp
- xstat_fs_test

Initialize the buffer.

(cherry picked from commit 211b6d6a4307006da1467b3be46912a3a5d7b20b)

(cherry picked from commit a6557ffa64d8fab3526c4f89629dcbb965a27780)

Change-Id: I6d334ae56c7c0e7c4acb1d7dbc59f785e0b47713

20 months agoOPENAFS-SA-2018-002 afs: prevent RXAFSCB_GetLock information leak
Mark Vitale [Tue, 26 Jun 2018 07:47:41 +0000]
OPENAFS-SA-2018-002 afs: prevent RXAFSCB_GetLock information leak

RXAFSCB_GetLock (cmdebug) does not correctly initialize its output.
This leaks kernel memory over the wire:

struct AFSDBLock
- up to 14 bytes for member name (16 - '<cellname>\0')

Initialize the buffer.

(cherry picked from commit b52eb11a08f2ad786238434141987da27b81e743)

(cherry picked from commit 3dea4adaa356b7eed40b6162c106c5e90690f5a1)

Change-Id: Ic76ba3c80b7d1173f31c1e54f0f004eac4ddef86

20 months agoOPENAFS-SA-2018-002 ptserver: prevent PR_ListEntries information leak
Mark Vitale [Tue, 26 Jun 2018 07:37:37 +0000]
OPENAFS-SA-2018-002 ptserver: prevent PR_ListEntries information leak

PR_ListEntries (pts listentries) does not properly initialize its output
buffers.  This leaks ptserver memory over the wire:

struct prlistentries
- up to 62 bytes for each entry name (PR_MAXNAMELEN 64 - 'a\0')

Initialize the buffer, and remove the now redundant memset for the
reserved fields.

(cherry picked from commit 9d1aeb5d761581a35bef2042e9116b96e9ae3bf5)

(cherry picked from commit e19ad4cdde463d2bbb4b815525da992bd5fc2648)

Change-Id: I441f54edb218eb8ce018a07394bb6e9d706d353a

20 months agoOPENAFS-SA-2018-002 volser: prevent AFSVolMonitor information leak
Mark Vitale [Tue, 26 Jun 2018 07:00:02 +0000]
OPENAFS-SA-2018-002 volser: prevent AFSVolMonitor information leak

AFSVolMonitor (vos status) does not properly initialize its output
buffers.  This leaks information from volserver memory:

struct transDebugInfo
- up to 29 bytes in member lastProcName (30-'\0')
- 16 bytes in members readNext, tranmitNext, lastSendTime,
  lastReceiveTime

Initialize the buffers.  This must be done on a per-buffer basis inside
the loop, since realloc is used to expand the storage if needed,
and there is not a standard realloc API to zero the newly allocated storage.

[kaduk@mit.edu: update commit message]

(cherry picked from commit 26924fd508b21bb6145e77dc31b6cd0923193b72)

(cherry picked from commit 2d22756de7af2c72b8aca6969825f8e921f01d6c)

Change-Id: Id819ffc2774cf5cb374ca19b7040282ba542654b

20 months agoOPENAFS-SA-2018-002 volser: prevent AFSVolPartitionInfo(64) information leak
Mark Vitale [Tue, 26 Jun 2018 06:33:05 +0000]
OPENAFS-SA-2018-002 volser: prevent AFSVolPartitionInfo(64) information leak

AFSVolPartitionInfo and AFSVolPartitionInfo64 (vos partinfo) do not
properly initialize their reply buffers.  This leaks the contents of
volserver memory over the wire:

AFSVolPartitionInfo (struct diskPartition)
- up to 24 bytes in member name (32-'/vicepa\0'))
- up to 12 bytes in member devName (32-'/vicepa/Lock/vicepa\0'))

AFSVolPartitionInfo64 (struct diskPartition64)
- up to 248 bytes in member name (256-'/vicepa\0'))
- up to 236 bytes in member devName (256-'/vicepa/Lock/vicepa\0')

Initialize the output buffers.

[kaduk@mit.edu: move memset to top-level function scope of RPC handlers]

(cherry picked from commit 76e62c1de868c2b2e3cc56a35474e15dc4cc1551)

(cherry picked from commit 28edf734db08d3a8285e89d9d78aa21db726e4c7)

Change-Id: Ie9394b3ab7944dd053e4677a0f9621f155890554

20 months agoOPENAFS-SA-2018-002 ptserver: prevent PR_IDToName information leak
Mark Vitale [Mon, 25 Jun 2018 22:03:12 +0000]
OPENAFS-SA-2018-002 ptserver: prevent PR_IDToName information leak

SPR_IDToName does not completely initialize the return array of names,
and thus leaks information from ptserver memory:

- up to 62 bytes per requested id (PR_MAXNAMELEN 64 - 'a\0')

Use calloc to ensure that all memory sent on the wire is initialized,
preventing the information leak.

[kaduk@mit.edu: switch to calloc; update commit message]

(cherry picked from commit 70b0136d552a0077d3fae68f3aebacd985abd522)

(cherry picked from commit c8c8682bb0e84ee5289fac3063119ae524773f61)

Change-Id: I4adfb5071535fe89e80268feecbf3873e0a119f6

20 months agoMake OpenAFS 1.6.22.4 96/13296/3 openafs-stable-1_6_22-branch openafs-stable-1_6_22_4
Stephan Wiesand [Fri, 24 Aug 2018 14:03:17 +0000]
Make OpenAFS 1.6.22.4

Update configure version strings for 1.6.22.4. Note that macos kext
can be of form XXXX.YY[.ZZ[(d|a|b|fc)NNN]] where d dev, a alpha,
b beta, f final candidate so we have no way to represent 1.6.22.4.
Switch to 1.6.23 dev 4 for macOS.

Change-Id: I7f150ce5e6028151355f149f5c75d08f7390501a
Reviewed-on: https://gerrit.openafs.org/13296
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>

20 months agoUpdate NEWS for 1.6.22.4 95/13295/2
Stephan Wiesand [Fri, 24 Aug 2018 14:00:48 +0000]
Update NEWS for 1.6.22.4

Release notes for the OpenAFS 1.6.22.4 release

Change-Id: I1c2772f18d9d16e3d134bc03a7fff1262cc68bf6
Reviewed-on: https://gerrit.openafs.org/13295
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>

20 months agoLINUX: Update to Linux struct iattr->ia_ctime to timespec64 with 4.18 94/13294/2
Joe Gorse [Mon, 2 Jul 2018 20:36:04 +0000]
LINUX: Update to Linux struct iattr->ia_ctime to timespec64 with 4.18

With 4.18+ Linux kernels we see a transition to 64-bit time stamps by
default.

current_kernel_time() returns the 32-bit struct timespec.
current_kernel_time64() returns the 64-bit struct timespec64.

struct iattr->ia_ctime expects struct timespec64 as of 4.18+.

Timestamps greater than 31-bit rollover after 2147483647 or
January 19, 2038 03:14:07 UTC. This is the same approach taken by
the Linux developers for converting between timepsec64 and timespec.

Reviewed-on: https://gerrit.openafs.org/13241
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 0bc5c15029cf7e720731f1415fcf9dc972d57ef4)

Reviewed-on: https://gerrit.openafs.org/13268
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 554176bd236d772d670df9bdd2496facd5a4209a)

Reviewed-on: https://gerrit.openafs.org/13269
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
(cherry picked from commit f9ae26d3d17599b9966e6b0f2d04e77952e86176)

Change-Id: Ic67af8f83da40cc3571a5d0a87e18bac01f5b4bd
Reviewed-on: https://gerrit.openafs.org/13294
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>

20 months agoautoconf: refactor linux-checks.m4 93/13293/2
Michael Meffie [Sat, 30 Dec 2017 22:59:38 +0000]
autoconf: refactor linux-checks.m4

Further refactoring of the autoconf macros. Divy up the linux kernel
checks into smaller files.

This is a non-functional change. Care has been taken preserve the
ordering of the autoconf tests. Except for whitespace, the generated
configure file has not been changed by this refactoring.  This has been
verified with a 'diff -u -w -B' comparison of the generated configure
file before and after applying this commit.

Reviewed-on: https://gerrit.openafs.org/12844
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 6a2b85cd4c00a08e165cb96d2cb56bf87c6324bc)

Reviewed-on: https://gerrit.openafs.org/12878
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 0247eb0a8c154811f495142276029a617ae0825a)

Reviewed-on: https://gerrit.openafs.org/12980
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
(cherry picked from commit 3ac2b0fb23e41f848b29eea9b4d2b64aa769c796)

Change-Id: I0698da86e36da37ccbd3d5c76cefb3374397dc1e
Reviewed-on: https://gerrit.openafs.org/13293
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>

20 months agoautoconf: refactor ostype.m4 92/13292/2
Michael Meffie [Sat, 30 Dec 2017 17:12:59 +0000]
autoconf: refactor ostype.m4

Further refactoring of the autoconf macros. Move more linux and solaris
specific checks into their own files.

This is a non-functional change. Care has been taken preserve the
ordering of the autoconf tests. Except for whitespace, the generated
configure file has not been changed by this refactoring.  This has been
verified with a 'diff -u -w -B' comparison of the generated configure
file before and after applying this commit.

Reviewed-on: https://gerrit.openafs.org/12843
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 3c2e39bab7d927aa5f20d02a5e327927a4b2b553)

Reviewed-on: https://gerrit.openafs.org/12877
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit e05b0b10b942ba3585f6d5d505a282c2de95c243)

Reviewed-on: https://gerrit.openafs.org/12979
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
(cherry picked from commit e8b094d9b6147345fd0922396c5181f3da8bb481)

Change-Id: Ic47143fe0ea0702d8f10ee35ea6abb8f250ea45a
Reviewed-on: https://gerrit.openafs.org/13292
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>

20 months agoautoconf: refactor acinclude.m4 91/13291/2
Michael Meffie [Fri, 29 Dec 2017 19:24:28 +0000]
autoconf: refactor acinclude.m4

The acinclude.m4 is very large and often requires to be changed for
unrelated commits.  Divy up the large acinclude.m4 into a number of
smaller files to avoid so many contentions and to make the autoconf
system easier to maintain.

This is a non-functional change. Care has been taken preserve the
ordering of the autoconf tests. Except for whitespace, the generated
configure file has not been changed by this refactoring.  This has been
verified with a 'diff -u -w -B' comparison of the generated configure
file before and after applying this commit.

Reviewed-on: https://gerrit.openafs.org/12842
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit c72622a244e561173e86ffe88ee3c9a8c823a76a)

Reviewed-on: https://gerrit.openafs.org/12876
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit e54963757320adb95b0c73bbd84fb8bf34319210)

Reviewed-on: https://gerrit.openafs.org/12978
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>
(cherry picked from commit 9d004f20c3bb0ffeae043a053efdb378064311e7)

Change-Id: Iefb54c54da2c488ccea13d8c54b9ef8b46f7cfd8
Reviewed-on: https://gerrit.openafs.org/13291
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>

21 months agoautoconf: detect ctf-tools and add ctf to libafs 83/13083/2
Marcio Barbosa [Mon, 5 Feb 2018 21:16:17 +0000]
autoconf: detect ctf-tools and add ctf to libafs

CTF is a reduced form of debug information similar to DWARF and stab. It
describes types and function prototypes. The principal objective of the
format is to shrink the data size as much as possible so that it could
be included in a production environment. MDB, DTrace, and other tools
use CTF debug information to read and display structures correctly.

This commit introduces a new configure option called --with-ctf-tools.
This option can be used to specify an alternative path where the tools
can be found. If the path is not provided, the tools will be searched
in a set of default directories (including $PATH). The CTF debugging
information will only be included if the corresponding --enable-debug /
--enable-debug-kernel is specified.

Note: at the moment, the Solaris kernel module is the only module
benefited by this commit.

Reviewed-on: https://gerrit.openafs.org/12680
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 88cb536f99dc58fdbeb9fa6c47c26774241a0cb6)

Reviewed-on: https://gerrit.openafs.org/12902
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 96ce04c78b5f745424165494c9b76d7ce227eeaa)

Change-Id: I7f95e5eae2af9f5640e7031dccb79b0d6eb3e51d
Reviewed-on: https://gerrit.openafs.org/13083
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

21 months agoredhat: Make separate debuginfo for kmods work with recent rpm 53/13053/3
Stephan Wiesand [Thu, 26 Apr 2018 17:33:31 +0000]
redhat: Make separate debuginfo for kmods work with recent rpm

Commit 443dd5367e0cd9050ad39a6594c5be521271b4e9 introduced the
creation of separate debuginfo packages for kmod packages, and
commmit 387ae9536888419d7b101513e04e1c644e3218d6 moved the code
from the spec into the kmodtool script.

Recent versions of rpm (the issue was found on Fedora 27) extract
the debuginfo data from a copy of the original files having the
package version-release as a suffix. This broke the original
change since the regular expression passed to find-debuginfo.sh
no longer matched the name of the openafs.ko file. The file list
for the -debuginfo package remained empty, which caused rpmbuild
to fail.

Relax the regex to match the previous and current file names we
are after. It is possible but unlikely that .*openafs\.ko.* will
ever match any file not being a kernel module.

Reviewed-on: https://gerrit.openafs.org/13030
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 076b73e06df8240f209470ea6ee19b66eb4166c3)

Reviewed-on: https://gerrit.openafs.org/13036
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 8fa929c4cb72f07816b7ab09fcf3c8af6bc4d65d)

Change-Id: I396caa1d2040fb9ce9ba10d4db2c1b06fcaafe86
Reviewed-on: https://gerrit.openafs.org/13053
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

21 months agoredhat: PACKAGE_VERSION macro no longer exists 52/13052/3
Stephan Wiesand [Thu, 26 Apr 2018 17:50:06 +0000]
redhat: PACKAGE_VERSION macro no longer exists

Commit 0d0e7699c9f789214205fe6837cded1a4c95f9c0 replaced all uses
of the %PACKAGE_VERSION macro in the spec with the %version one, but
missed an instance in the kmodtool script. Fix this, to avoid a
warning during rpmbuild.

Reviewed-on: https://gerrit.openafs.org/13031
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit cfa74883e4996dfee2bd6ffaa3b967e5a7941e0b)

Reviewed-on: https://gerrit.openafs.org/13037
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit a83c74471644cc1f0d39de86cd5a1c54a4d594e7)

Change-Id: I8f04bf0567153fc698aef5a3ea2961e29d2c07eb
Reviewed-on: https://gerrit.openafs.org/13052
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

21 months agoredhat: Create unique debuginfo packages for kmods 29/13029/4
Stephan Wiesand [Mon, 26 Mar 2018 18:21:19 +0000]
redhat: Create unique debuginfo packages for kmods

Commit 443dd5367e0cd9050ad39a6594c5be521271b4e9 ("redhat:
separate debuginfo package for kmod rpm") introduced the
creation of separate debuginfo packages for the kmod packages.
As such, this is useful, but all debuginfo packages for a given
OpenAFS release ended up with the same name/version/release for
the kmod debuginfo package, no matter which kernel release or
variant the kmod was built for.

Move the additional black magic from the spec into the kmodtool
script where we have the means to do better: Use the same naming
and versioning conventions as for the kmod-openafs packages
themselves.

Reviewed-on: https://gerrit.openafs.org/12977
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 387ae9536888419d7b101513e04e1c644e3218d6)

Reviewed-on: https://gerrit.openafs.org/12986
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit a819cf483e03d32b2213175e19e628d7c3d8194d)

Change-Id: I55ea64a156c930f74aed47f92d4b80c14d54ad23
Reviewed-on: https://gerrit.openafs.org/13029
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

21 months agoredhat: separate debuginfo package for kmod rpm 18/12818/5
Pat Riehecky [Thu, 12 Mar 2015 19:33:10 +0000]
redhat: separate debuginfo package for kmod rpm

Place the debuginfo for the kmod into its own rpm so that
it doesn't have to track against the userspace packages.

FIXES 132034

Reviewed-on: https://gerrit.openafs.org/11867
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 443dd5367e0cd9050ad39a6594c5be521271b4e9)

Change-Id: I4b0783b2279cd3c295a92fcac1d0b2ad06e89376
Reviewed-on: https://gerrit.openafs.org/12818
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

21 months agoafs: Fix bounds check in PNewCell 62/13062/2
Benjamin Kaduk [Tue, 28 Nov 2017 04:17:28 +0000]
afs: Fix bounds check in PNewCell

Reported by the opensuse buildbot:

CC [M] /home/buildbot/opensuse-tumbleweed-i386-builder/build/src/libafs/MODLOAD-4.13.12-1-default-MP/rx_packet.o
/home/buildbot/opensuse-tumbleweed-i386-builder/build/src/afs/afs_pioctl.c: In function ‘PNewCell’:
/home/buildbot/opensuse-tumbleweed-i386-builder/build/src/afs/afs_pioctl.c:3075:55: error: ‘*’ in boolean context, suggest ‘&&’ instead [-Werror=int-in-bool-context]
     if ((afs_pd_remaining(ain) < AFS_MAXCELLHOSTS +3) * sizeof(afs_int32))
         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~

The bug was introduced in commit 718f85a8b6.

Reviewed-on: https://gerrit.openafs.org/12782
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 4fa0ee620cfb9991ca9748b5ee116cc8e1e6c505)

Reviewed-on: https://gerrit.openafs.org/12784
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit e2c47cae56ba0d804af119fb158a9fe77fa3a15e)

Change-Id: I1e730e274173aa872b3d6ca5dff8276b8c9d3188
Reviewed-on: https://gerrit.openafs.org/13062
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

21 months agoLINUX: Don't compile syscall code with keyrings 61/13261/2
Andrew Deason [Mon, 9 Mar 2015 23:01:29 +0000]
LINUX: Don't compile syscall code with keyrings

osi_syscall_init() is not currently called if we have kernel keyrings
support, since we don't need to set up or alter any syscalls if we
have kernel keyrings (we track PAGs by keyrings, and we use ioctls
instead of the AFS syscall now).

Since we don't call it, this commit makes us also not compile the
relevant syscall-related code. This allows new platforms to be added
without needing to deal with any platform-specific code for handling
32-bit compat processes and such, since usually we don't need to deal
with intercepting syscalls.

To do this, we just define osi_syscall_init and osi_syscall_cleanup as
noops if we have keyrings support. This allows us to reduce the #ifdef
clutter in the actual callers.

Note that the 'afspag' module does currently call osi_syscall_init
unconditionally, but this seems like an oversight. With this change,
the afspag module will no longer alter syscalls when we have linux
keyrings support.

Reviewed-on: https://gerrit.openafs.org/11936
Reviewed-by: Chas Williams <3chas3@gmail.com>
Reviewed-by: Perry Ruiter <pruiter@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 32901c58b29ba4ac666f1dba9915cae2c1f03b52)

Change-Id: I95fb6fffc78dacef00033178acd78ad04521ae13
Reviewed-on: https://gerrit.openafs.org/13261
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

21 months agoviced: SRXAFS_InlineBulkStatus set InterfaceVersion on error 34/13234/2
Jeffrey Altman [Fri, 11 May 2018 19:44:24 +0000]
viced: SRXAFS_InlineBulkStatus set InterfaceVersion on error

AFSFetchStatus.InterfaceVersion is required to be "1" for any
of the fields in the structure to be considered valid.  Therefore,
InterfaceVersion must be set to one when returning an 'errorCode'
value.

When RXAFS_InlineBulkStatus was introduced by OpenAFS in
362d26c733b086d26f013bd229af979a112098f5 not only wasn't
InterfaceVersion set but neither was the memory allocated
to OutStats initialized.  As a result the InterfaceVersion field
value could be not only zero but random.  The OutStats memory
was initialized to zeros beginning with
726e1e13ff93e2cc1ac21964dc8d906869e64406.

Reviewed-on: https://gerrit.openafs.org/13067
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit f045de21a45fcc8f71e2b30e826c22c8a7b4d0f2)

Reviewed-on: https://gerrit.openafs.org/13117
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 8ca1b87d0804b23e32304742297701960489f1b4)

Change-Id: I9ec854546a6e65e88a6696d430a40ca539aa3a46
Reviewed-on: https://gerrit.openafs.org/13234
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

21 months agoubik: clones should not request votes 23/13223/2
Marcio Barbosa [Tue, 15 May 2018 21:10:45 +0000]
ubik: clones should not request votes

Clones should not be able to become the sync-site. To make it possible,
regular sites do not vote for a site tagged as clone. In other words,
the clones ask for votes but they cannot be the sync-site. Knowing that
their requests for votes should be refused by the regular sites, they
should never have enough votes to win the election.

In addition to the unnecessary network traffic created by these
unnecessary requests, this current approach can be problematic in some
specific situations. As an example, consider the following scenario:

    The user wants to turn a regular site, called host1, into a clone.
    To do so, he runs the following commands on every single server:

    $ bos removehost -server <server> -host host1
    $ bos addhost -server <server> -host host1 -clone

After that, he restarts the servers, one by one. Depending on the delay
between the restarts, a clone can become the sync-site. This is possible
because the clones request votes from the other sites. If enough regular
sites are not aware (yet) that the request for vote came from a clone,
the clone in question can get enough votes to win the election.

To fix the problems mentioned above, do not request votes if you cannot
be the sync-site.

Reviewed-on: https://gerrit.openafs.org/12654
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 3cc22a442e1dad628f0b11a32c4037fc7174dde4)

Reviewed-on: https://gerrit.openafs.org/13116
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit eb607b67793c37f57490ece47f93c65383a2fdf5)

Change-Id: I323a6f50113b9ab66b04d070b24e5f1547005adf
Reviewed-on: https://gerrit.openafs.org/13223
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

21 months agoLINUX: Update to Linux struct iattr->ia_ctime to timespec64 with 4.18 69/13269/2
Joe Gorse [Mon, 2 Jul 2018 20:36:04 +0000]
LINUX: Update to Linux struct iattr->ia_ctime to timespec64 with 4.18

With 4.18+ Linux kernels we see a transition to 64-bit time stamps by
default.

current_kernel_time() returns the 32-bit struct timespec.
current_kernel_time64() returns the 64-bit struct timespec64.

struct iattr->ia_ctime expects struct timespec64 as of 4.18+.

Timestamps greater than 31-bit rollover after 2147483647 or
January 19, 2038 03:14:07 UTC. This is the same approach taken by
the Linux developers for converting between timepsec64 and timespec.

Reviewed-on: https://gerrit.openafs.org/13241
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 0bc5c15029cf7e720731f1415fcf9dc972d57ef4)

Reviewed-on: https://gerrit.openafs.org/13268
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 554176bd236d772d670df9bdd2496facd5a4209a)

Change-Id: I0804e05f2a0004669b8b089e4f2f23d1df6c9133
Reviewed-on: https://gerrit.openafs.org/13269
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

2 years agorx: Do not count RXGEN_OPCODE towards abort threshold 29/12929/2
Jeffrey Altman [Sat, 10 Feb 2018 15:47:24 +0000]
rx: Do not count RXGEN_OPCODE towards abort threshold

An RXGEN_OPCODE is returned for opcodes that are not implemented by the
rx service.  These opcodes might be deprecated opcodes that are no
longer supported or more recently registered opcodes that have yet to
be implemented.  Clients should not be punished for issuing unsupported
calls.  The clients might be old and are issuing no longer supported
calls or they might be newer and are issuing yet to be implemented calls
as part of a feature test and fallback strategy.

This change ignores RXGEN_OPCODE errors when deciding how to adjust the
rx_call.abortCount.  When an RXGEN_OPCODE abort is sent the
rx_call.abortCount and rx_call.abortError are left unchanged which
preserves the state for the next failing call.

Note that this change intentionlly prevents the incrementing of the
abortCount for client connections as they never send delay aborts.

Reviewed-on: https://gerrit.openafs.org/12906
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit f82d1c7d5aeae148305e867c1f79c6ea2f9e0a2a)

Reviewed-on: https://gerrit.openafs.org/12914
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 774df869fc1753e94f79c6a0b617b7adb9e4060c)

Change-Id: I58d77ada0724cdb8231eaeba94d6661e87b2574a
Reviewed-on: https://gerrit.openafs.org/12929
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

2 years agoubik: Log sync site for SDISK_SendFile USYNC error 28/13028/2
Andrew Deason [Wed, 7 Mar 2018 17:32:43 +0000]
ubik: Log sync site for SDISK_SendFile USYNC error

In SDISK_SendFile, we return a USYNC error if the caller is not the
sync site. Say who the sync site is when we do this, to possibly help
post-mortem debugging.

Reviewed-on: https://gerrit.openafs.org/12943
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit c44f6f7a8052bdd1fb021e07bb6ae142b61e6b5b)

Reviewed-on: https://gerrit.openafs.org/12948
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 72b2da46bb0f997d70cca3cca7abc4a135d3d500)

Change-Id: I393ae8d880fd3dfa48ee0a908a68d2b433160f2e
Reviewed-on: https://gerrit.openafs.org/13028
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

2 years agoubik: don't set database epoch to 0 if not needed 27/13027/2
Marcio Barbosa [Thu, 22 Feb 2018 22:53:23 +0000]
ubik: don't set database epoch to 0 if not needed

If our attempt to receive a fresh database from a peer fails, we will
overwrite the version.epoch field of our current local copy of the
database with an invalid value, "0". The idea behind this approach is
to make sure that this database will not be seen as a legit copy if the
transfer is not completed properly. Although it is questionable if this
approach is still necessary (since the current version writes the data
into a temporary file), it is undisputed that the database version does
not have to be invalidated if the transfer fails in a early stage where
no data has been written and we could safely continue to reuse the local
copy for read-only queries. Early failures may happen if:

1. The peer sending the database to us is not the peer we believe to be
the sync site;

2. The sender is not authorized to call DISK_SendFile;

In both cases, the database epoch is invalidated. As a result of that,
we may have the following consequences:

1. Reads may not be allowed

Once the on disk epoch is invalidated, if the server in question is
rebooted, the invalid on disk epoch will be used to initialize the in
memory epoch. At this point, reads may not be allowed since
urecovery_AllBetter checks if the in memory epoch is greater than 1.
Reads should not be blocked forever since the sync-site will send a new
database to this remote and, as a result of that, the invalid version
will be corrected.

2. Data can be lost

If the site with the invalid epoch is the one with the most recent
database, the database can be rolled back to an earlier version during a
new quorum establishment. Consider the following scenario where we have
three sites:

Site A (up - database up to date) (sync-site)
Site B (up - database up to date)
Site C (down - old database)

The epoch of B is invalidated due to the problem fixed by this patch.
Then, A is turned off and C is turned on. In this scenario, the new
sync-site will distribute the old database held by C since its epoch is
greater than 0.

To fix the problem in question, do not set the database epoch to 0
if the local database was not modified.

Acknowledgements:

Hartmut Reuter <hartmut.reuter@gmx.de>
    - found the problem;
    - suggested a possible solution;

Benjamin Kaduk <kaduk@mit.edu>
    - submitted the first version;

Andrew Deason <adeason@sinenomine.net>
    - suggested changes;

Reviewed-on: https://gerrit.openafs.org/12924
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
(cherry picked from commit bd6a2484011dad6298c4ce97dd0cd68e0834baa5)

Reviewed-on: https://gerrit.openafs.org/12937
Reviewed-by: Hartmut Reuter <reuter@rzg.mpg.de>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit b41065f2b8877580a7e1858b8e2857973ddf6503)

Change-Id: I0923dddd2bf32f97230f3addb2fc376c0b2fa85c
Reviewed-on: https://gerrit.openafs.org/13027
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

2 years agoafs_pioctl: avoid -Wpointer-sign 22/13022/3
Benjamin Kaduk [Fri, 2 Mar 2018 02:28:23 +0000]
afs_pioctl: avoid -Wpointer-sign

Change the declaration of 'addr' to be a signed int, to match
RXAFS_CallBackRxConnAddr() and the afsd_pd_GetInt() used with it.
This was detected by clang 4.0 in FreeBSD 11.1, via -Wpointer-sign.

Reviewed-on: https://gerrit.openafs.org/12934
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 79f33b859aeb3c91f2cce7597fdc138978c4e1d9)

Reviewed-on: https://gerrit.openafs.org/12938
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit acb0e84df0cdff1ee1b4098b2705e5a30dd7eb38)

Change-Id: I5317ee2669c8906608cd087bad9c8162f9cc124f
Reviewed-on: https://gerrit.openafs.org/13022
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

2 years agoafs: improve -volume-ttl error messages 23/13023/2
Michael Meffie [Tue, 20 Feb 2018 16:51:01 +0000]
afs: improve -volume-ttl error messages

Change the afs call which sets the volume ttl value to return EFAULT
instead of EINVAL when given an out of range value for the volume ttl
parameter.  This is more consistent with the other op codes, which
return EFAULT when given an out of range parameter and allows the caller
to distinguish between an invalid opcode and a bad parameter.

Move the volume ttl range constants to afs_args.h, which is where
constants related to the op codes are supposed to be defined. This makes
the constants available to the caller in afsd.c as well as the
implementation in afs_call.c.

Update afsd to print a more sensible error message when the volume ttl
set calls fails due to an out of range parameter.

Reviewed-on: https://gerrit.openafs.org/12918
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 6d74e3d6a1becf86cec30efc2d01a5692167afe1)

Reviewed-on: https://gerrit.openafs.org/12936
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 0b1d10fd2535b0059d1e88c23fbd3f60041edc9f)

Change-Id: I3ed43d819e4d1b5aff7e9108fc485b2358dd6d25
Reviewed-on: https://gerrit.openafs.org/13023
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

2 years agoFBSD: param.h consistency 24/13024/2
Stephan Wiesand [Wed, 4 Apr 2018 15:09:39 +0000]
FBSD: param.h consistency

Commit 88dc4d93f5ef080da8f56fac453f095e6c79d4a0 ("Add param.h
files for recent FreeBSD") introduced an inconsistency between
the i386 and amd64 param.h files for 11.1 and 12.0 regarding
the *_FBSD101_ENV #defines.

Citing Benjamin Kaduk: "Traditionally we have the param.h for
a FreeBSD N.0 release include the (N-1).Y values that existed
at the time of the N.0 release, and freeze that set of (N-1).Y
values for the lifetime of FreeBSD N.x, if that makes sense."

Given that FreeBSD 11.0 was released shortly after 10.3, and
12.0 is not yet released, consistently #define
*_FBSD10{1..3}_ENV for 11.1 and *_FBSD10{1..4}_ENV for 12.0

Reviewed-on: https://gerrit.openafs.org/12990
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 154512831966d12c1e32e6271d4ab1440a25b96e)

Reviewed-on: https://gerrit.openafs.org/12997
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit b30f21b8ec494d921c6ac513bf1022d5937ba220)

Change-Id: Ic887d86e23567af04b6ee50d460ff1db8a263414
Reviewed-on: https://gerrit.openafs.org/13024
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

2 years agoAdd param.h files for recent FreeBSD 85/12985/2
Benjamin Kaduk [Tue, 9 Jan 2018 04:28:24 +0000]
Add param.h files for recent FreeBSD

Add files for FreeBSD 10.4, 11.1, and 12.0 (12-CURRENT), for i386 and amd64.

Reviewed-on: https://gerrit.openafs.org/12863
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 88dc4d93f5ef080da8f56fac453f095e6c79d4a0)

Reviewed-on: https://gerrit.openafs.org/12888
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 07811e3b15de8926d63b423804c620bc3501745b)
[updated to match the FreeBSD param.h files on openafs-stable-1_6_x]

Change-Id: I234527b1b2b75d901c43163acb1045310dcffab4
Reviewed-on: https://gerrit.openafs.org/12985
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

2 years agoCellServDB update 14 Mar 2017 28/12928/3
Michael Meffie [Mon, 8 Feb 2016 17:12:22 +0000]
CellServDB update 14 Mar 2017

Update all remaining copies of CellServDB in the tree, and make the
Red Hat packaging use it by default too.

[stephan.wiesand@desy.de: added update for the src/packaging/Debian
instance only present on the 1.6.x branch]

Reviewed-on: https://gerrit.openafs.org/12880
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 3ca1352170f87994d42578c5bc75e52c4103bc69)

Reviewed-on: https://gerrit.openafs.org/12889
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 0798b54b258f48cae8a5b1b3e107a22693d37937)

Change-Id: Ice76ee3d210d948ef0ab7bd92c2cc73b6c75b707
Reviewed-on: https://gerrit.openafs.org/12928
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

2 years agoAvoid gcc warning 75/12975/2
Christof Hanke [Mon, 18 Dec 2017 15:58:39 +0000]
Avoid gcc warning

When using the configure option --enable-checking with gcc 7.2.1,
the compilation fails with

vutil.c:860:20: error: ‘%s’ directive writing up to 255 bytes into \
a region of size 63 [-Werror=format-overflow=]

This can be seen in the logs of the openSUSE Tumbleweed builder
for e.g. build 2368.
Avoid this warning by using snprintf which is provided by libroken
for all platforms.

Reviewed-on: https://gerrit.openafs.org/12813
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit fd4eaebb60dbefc27be98015fee23a3cf5d9752d)

Reviewed-on: https://gerrit.openafs.org/12897
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 4988628a2e41955951a49ea0032cabe13f9337d3)

Change-Id: I6b48d49c2d3d42762c6b5bf2758db0b33838751d
Reviewed-on: https://gerrit.openafs.org/12975
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

2 years agoMake OpenAFS 1.6.22.3 09/13009/2 openafs-stable-1_6_22_3
Stephan Wiesand [Thu, 12 Apr 2018 15:17:10 +0000]
Make OpenAFS 1.6.22.3

Update configure version strings for 1.6.22.3. Note that macos kext
can be of form XXXX.YY[.ZZ[(d|a|b|fc)NNN]] where d dev, a alpha,
b beta, f final candidate so we have no way to represent 1.6.22.3.
Switch to 1.6.23 dev 3 for macOS.

Change-Id: I5ee43eea7eb19c114400e9824a148a5348ef82d6
Reviewed-on: https://gerrit.openafs.org/13009
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>

2 years agoUpdate NEWS for 1.6.22.3 13/13013/3
Stephan Wiesand [Fri, 13 Apr 2018 12:59:15 +0000]
Update NEWS for 1.6.22.3

Release notes for the OpenAFS 1.6.22.3 release

Change-Id: I031b1a6d073a71de8b553d087f8c21af76ace0f0
Reviewed-on: https://gerrit.openafs.org/13013
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>

2 years agoLINUX: fix RedHat 7.5 ENOTDIR issues 12/13012/2
Mark Vitale [Fri, 2 Mar 2018 04:16:56 +0000]
LINUX: fix RedHat 7.5 ENOTDIR issues

Red Hat Linux 7.5 beta introduces a new file->f_mode flag
FMODE_KABI_ITERATE as a means for certain in-tree filesystems to
indicate that they have implemented file operation iterate() instead of
readdir().  The kernel routine iterate_dir() tests this flag to decide
whether to invoke the file operation iterate() or readdir().

The OpenAFS configure script detects that the file operation iterate()
is available under RH7.5 and so implements iterate() as
afs_linux_readdir().  However, since OpenAFS does not set
FMODE_KABI_ITERATE on any of its files, the kernel's iterate_dir() will
not invoke iterate() for any OpenAFS files.  OpenAFS has also not
implemented readdir(), so iterate_dir() must return -ENOTDIR.

Instead, modify OpenAFS to fall back to readdir() in this case.

Reviewed-on: https://gerrit.openafs.org/12935
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit c818f86b79a636532d396887d4f22cc196c86288)

Reviewed-on: https://gerrit.openafs.org/12950
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit b73863b8d2669830a17c097abf1d846d0108a2f4)

Reviewed-on: https://gerrit.openafs.org/12971
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>
(cherry picked from commit a22ad3923d356c49a10e905248066b69be01b8c2)

Change-Id: I5f4d301b4e865a0880513e0b4e027c41659b4f15
Reviewed-on: https://gerrit.openafs.org/13012
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>