Marcio Barbosa [Mon, 18 Nov 2019 14:34:08 +0000 (06:34 -0800)]
macos: add support for MacOS 10.15
This commit introduces the new set of changes / files required to
successfully build the OpenAFS source code on OS X 10.15 "Catalina".
Reviewed-on: https://gerrit.openafs.org/13668 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 93815caabc92acc6edc62b72805b44d2e46748cf)
Change-Id: Ia1fb98dd59d7b0ddad9c16c04b823623e07dd498
Reviewed-on: https://gerrit.openafs.org/14033 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Marcio Barbosa [Fri, 13 Dec 2019 03:03:04 +0000 (19:03 -0800)]
macos: upgrade *.xib files
According to Xcode 11, the *.xib files updated by this commit use an
older format that is potentially insecure when decoded. To fix this
problem, Xcode automatically upgraded these files to the modern format.
These changes are required to build OpenAFS on Catalina (Xcode 11).
Reviewed-on: https://gerrit.openafs.org/13935 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit d4302d42149988fa6d04d626967063dfa916c9fd)
Change-Id: I1e29493a8431d4ad13ff36762f6112dd5309573c
Reviewed-on: https://gerrit.openafs.org/14032 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Marcio Barbosa [Fri, 8 Nov 2019 02:56:13 +0000 (23:56 -0300)]
macos: tell the compiler the system include path
In order to support multiple SDKs, macOS Catalina no longer has the
/usr/include directory. As a result, the compiler needs to know where
these headers can be found. To successfully build OpenAFS on OSX 10.15,
set KROOT so the compiler knows the correct location of these headers.
Reviewed-on: https://gerrit.openafs.org/13936 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 677b038814817defec9421e698ce67b44a7fd7d1)
Change-Id: I2043c2bc6e745ca55faf68b77d791168bc57bb1d
Reviewed-on: https://gerrit.openafs.org/14031 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Marcio Barbosa [Thu, 14 Nov 2019 20:29:56 +0000 (17:29 -0300)]
viced: add opt to allow admin writes on RO servers
Add the new option -admin-write to allow write requests from superusers
on file servers running in readonly mode (-readonly). This lets sites
run fileservers in readonly mode for normal users, but allows members of
the system:administrators group to modify content.
Reviewed-on: https://gerrit.openafs.org/13707 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit f5f8b9336919debc5c26c429b12a14b65e0b697c)
Change-Id: Ia627b8c99767a875c1e8d1c69dcb45118df36937
Reviewed-on: https://gerrit.openafs.org/14019 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Marcio Barbosa [Thu, 14 Nov 2019 04:15:47 +0000 (01:15 -0300)]
viced: prevent writes on readonly fileservers
Currently, a fileserver can be initialized as readonly. In this mode,
writes on this server should not be allowed. Unfortunately, updates on
files stored by readonly fileservers are not completely prevented. In
some situations, the check for RO server is omitted (e.g. if the user is
the owner of the file to be updated). In other situations, the same
check is redundant.
To fix these problems, consolidate this check in one place.
Reviewed-on: https://gerrit.openafs.org/13934 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 0593017177edd5b3bc6609d9dfcce55f15bba3e9)
Change-Id: I42034928d1f5e9342029121613ac8d716818c3ae
Reviewed-on: https://gerrit.openafs.org/14018 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Mon, 18 Nov 2019 02:58:15 +0000 (20:58 -0600)]
afs: Ensure CDirty is set during afs_write loop
Currently, in afs_write(), we set CDirty on the given vcache, and then
write the given data into various dcaches. When writing to a dcache,
we call afs_DoPartialWrite, which may cause us to flush the dirty data
to the fileserver and clear the CDirty bit.
If we were given more than 1 chunk of data to write, we will then go
through another iteration of the loop, writing more dirty data into
dcaches, but CDirty will not be set. This can cause issues with, for
example, afs_SimpleVStat() or afs_ProcessFS(), which use CDirty to
determine whether or not to merge in FetchStatus info from the
fileserver into our local cache. This can cause our local cache to
incorrectly reflect the state of the file on the fileserver, instead
of the state of the locally-modified file in our cache.
A more detailed example is as follows. Consider a small C program that
copies a file, fchmod()ing the destination before closing it:
Currently, on FBSD, using this to copy a 7862648-byte file, using a
smallish cache (10000 blocks) will cause the destination to appear to
be truncated, because avc->f.m.Length will be incorrect, even though
all of the relevant data was written to the fileserver.
On most other platforms such as SOLARIS and LINUX, this is not a
problem, since currently they only write one page of data at a time to
afs_write(), and so they never hit multiple iterations of the while()
loop inside afs_write().
To fix this, just set CDirty on every iteration of the while() loop in
afs_write(). In general, we need to set CDirty after calling
afs_DoPartialStore() anywhere if the caller continues to write more
data. But all callers already do this, except for this one instance in
afs_write().
Thanks to tcreech@tcreech.com for helping find occurrences of the
relevant issue.
FIXES 135041
Reviewed-on: https://gerrit.openafs.org/13948 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 9d0854547522f7b2fb1bb7aa876fe9f901674747)
Change-Id: Ie86313e9b9750bc6724bb6e18b7df8e010810023
Reviewed-on: https://gerrit.openafs.org/13951 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Tue, 5 Nov 2019 02:03:43 +0000 (20:03 -0600)]
afs: Avoid -1 error for vreadUIO/vwriteUIO
Commit c6b61a45 (afs: Verify osi_UFSOpen worked) added various checks
to return an error if a given osi_UFSOpen failed. However, two of
these checks (in afs_UFSReadUIO and afs_UFSWriteUIO) result in us
returning -1 on error, in functions that otherwise return errno codes
(e.g. ENOSPC). An error code of -1 might get interpreted as
RX_CALL_DEAD, which would be rather confusing, so use EIO as a generic
error instead.
Reviewed-on: https://gerrit.openafs.org/13931 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 360b9d5d71fb1de142ae4efd4660732476855a3f)
Change-Id: I4c6773affe02cc7a3ca01cf25bea21c960d98e87
Reviewed-on: https://gerrit.openafs.org/13938 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Michael Meffie [Mon, 22 Jul 2019 19:20:24 +0000 (15:20 -0400)]
vos: fix name availability check in vos rename
The UV_RenameVolume() function first updates the volume name in the
VLDB, then read-write volume header and backup volume header, and
finally all of the read-only volume headers. If this function is
interrupted or a remote site is not reachable, the names in some of the
volume headers will be out of sync with name in the VLDB entry.
The implementation of UV_RenameVolume() is idempotent, so can be safely
called with the same name as in the volume's VLDB entry. This could be
used to bring all the names in the volume headers in sync with the name
in the VLDB.
Unfortunately, due to the check of the -newname parameter, vos
rename will not invoke UV_RenameVolume() when the name in the VLDB has
already been changed. The vos rename command attempts to verify the
desired name (-newname) is available before invoking UV_RenameVolume()
by simply checking if a VLDB entry exists with that name, and
incorrectly assumes when a VLDB entry exists with that name it is an
entry for a different volume.
Change the -newname check to allow vos rename to proceed when name has
already been set in the VLDB entry of the volume being renamed. This
allows admins to run vos rename command to complete a previously
incomplete rename operation and bring the names in the volume headers in
sync with the name in the VLDB entry.
Note: Before this commit, administrators could workaround this vos
rename limitation by renaming the volume twice, first to an unused
volume name, then to the actual desired volume name.
Remove the useless checks of the code1 return code after exit in
the RenameVolume() function. These checks for code1 are never performed
since the function exits early when the first VLDB_GetEntryByName()
fails for any reason.
Update the vos rename man page to show vos rename can be used to fix
previously interrupted/failed rename. Also document the -oldname
parameter accepts a numeric volume id to specify the volume to be
renamed.
Reviewed-on: https://gerrit.openafs.org/13720 Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 9238b1eb9ef02889855eaade76e5b7962e5f2f28)
Change-Id: I8b03e4211c5d306f55779130c8461b14bc4913f0
Reviewed-on: https://gerrit.openafs.org/14055 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Mark Vitale [Fri, 4 May 2018 21:32:51 +0000 (17:32 -0400)]
ubik: improve logging for database synchonizations
As an aid for debugging database synchronization issues, ensure that the
logging is consistent and unambiguous for both the client and server
sides of DISK_GetFile and DISK_SendFile. Add new error messages as
required.
In addition, rework the "recovery sending version to <IP>" message in
urecovery_Interact. This message is misleading because the new version
database is only sent to a DB server if its version is not up to date.
Instead, move this message into the version check block immediately
below it. Also reword it for clarity and promote its log level from 5
to 0. Finally, remove the now-superfluous "recovery stating local
database" log message.
Reviewed-on: https://gerrit.openafs.org/13079 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 0e1c042615d1aeb919a22568cdd2b2ea42c677ba)
Change-Id: I26e876e5bcd5adc004b985ea8c3f716cb6a72b5d
Reviewed-on: https://gerrit.openafs.org/13908 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Mark Vitale [Fri, 17 Mar 2017 22:12:23 +0000 (18:12 -0400)]
ubik: urecovery_AbortAll diagnostic msgs
As a troubleshooting aid for developers, add a few counters and a log
msg so we know when transactions are being aborted (if any) by
urecovery_AbortAll.
Reviewed-on: https://gerrit.openafs.org/12618 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
(cherry picked from commit eac22d3e46c72c0e2b82f35c5187d50b6fa136a2)
Change-Id: Ia91bc1c5f041eccc9b974d4b195fed1a889252e7
Reviewed-on: https://gerrit.openafs.org/13907 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>
Mark Vitale [Tue, 9 May 2017 01:11:27 +0000 (21:11 -0400)]
ubik: log important messages at default log level
Many important ubik messages (e.g., errors, warnings, sync state
changes) are logged at log level 5 (-d 5) or higher. Many sites are
reluctant to run ubik servers at a logging level higher than the default
due to the large number of extremely noisy informational messages at log
level 5. Therefore, many important log messages are never seen.
Instead, issue critical errors, warnings, and other important messages
at log level 0 so that they are always seen, even at the default logging
level.
In addition, disambiguate the two "I am no longer sync-site" messages by
adding a unique reason text to each.
Reviewed-on: https://gerrit.openafs.org/12617 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
(cherry picked from commit 8b0e312d043d435f0e55c6dc14f5446ffedc7ce4)
Change-Id: I87425e78fb4f7fb1aa393b2f5b81ab34a71a38c4
Reviewed-on: https://gerrit.openafs.org/13906 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Fri, 27 Jul 2018 18:36:15 +0000 (13:36 -0500)]
ubik: Save errno before logging
The value of errno can change after a syscall, and ViceLog may issue
syscalls (such as write()). So, make sure we save errno here before
calling ViceLog().
Issue spotted by kaduk@mit.edu.
Reviewed-on: https://gerrit.openafs.org/13263 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 9ff5f8f7601cc9761cc6a4ef0e8b7c8c2c8dddb5)
Change-Id: I4f41ca758574e0d58659788467372af71a5f75f2
Reviewed-on: https://gerrit.openafs.org/13898 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Marcio Barbosa [Sat, 11 Aug 2018 17:17:28 +0000 (13:17 -0400)]
vol: remove empty directories left by vos zap -force
The vos zap -force command does not remove the directories associated
with the volume in question (AFS_NAMEI_ENV). When the vos zap -force
command is executed, the volume server goes through the /vicep*/AFSIDat
directories and removes the files associated with the volume id received
as an argument. Unfortunately, the volume server does not remove the
directories associated with this volume. As a result, empty directories
are left behind.
To fix this problem, remove the empty directories left behind when vos
zap -force is executed.
Reviewed-on: https://gerrit.openafs.org/12879 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 892045a9803ed471986569705d9d727165ca7ecf)
Change-Id: I18b727a561785443f488d60b967182e3ddb9064e
Reviewed-on: https://gerrit.openafs.org/13897 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Benjamin Kaduk [Sat, 2 Feb 2019 18:49:07 +0000 (12:49 -0600)]
vol: check snprintf return values in namei_ops
gcc8 is more aggressive about parsing format strings and computing bounds
on the generated text from functions like snprintf. In this case it seems best
to detect cases of truncation and error out, rather than trying to increase
stack buffer sizes or switch to asprintf. These paths should be well-behaved
since they are local to the fileserver, so this is mostly about appeasing the
compiler's -Wformat-truncation checks to allow us to build with --enable-checking.
Reviewed-on: https://gerrit.openafs.org/13463 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 8632f23d6718a3cd621791e82d1cf6ead8690978)
Change-Id: Ie8f9005ad9cf7cdfd3eb472e01a6fdbde5b7e57e
Reviewed-on: https://gerrit.openafs.org/13732 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Marcio Barbosa [Tue, 31 May 2016 12:08:08 +0000 (09:08 -0300)]
venus: fix memory leak
In GetPrefCmd, when we request server prefs from the kernel and our
output buffer is not big enough, pioctl() will return E2BIG and we
allocate more memory and try again. However, if the size of the output
buffer reaches 16k bytes and this space is still not enough (or if
pioctl fails and errno != E2BIG), we return without releasing the
memory that was previously allocated.
To fix this problem, free our output buffer when this happens.
Reviewed-on: https://gerrit.openafs.org/12293 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 8ad4e15ffc883c9a99f9636d7d8a5ed0a2fcc26a)
Change-Id: I62ceddc5284c94da205ec2351ab9ef970cd64c4a
Reviewed-on: https://gerrit.openafs.org/13895 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Benjamin Kaduk [Sat, 2 Feb 2019 23:09:36 +0000 (17:09 -0600)]
venus: appease gcc8's -Wformat-string
Interestingly, even before this commit, the buffer size was larger
than what the kernel would accept. Since the kernel does its own
length checking, it's simplest to just allow slightly larger requests
here and have them fail later.
Reviewed-on: https://gerrit.openafs.org/13471 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit dff81f1b78fecc54f5af91f7d728925ffca62d2c)
Change-Id: Ie19d887abebdd3603a04c06723f5cb750eb654f8
Reviewed-on: https://gerrit.openafs.org/13740 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Michael Meffie [Thu, 21 Dec 2017 16:59:38 +0000 (11:59 -0500)]
vol: avoid query for parent id when deleting disk header
When a DAFS volume server removes a volume disk header file (V*.vol),
the volume server invokes an fssync command to have the file server
delete the Volume Group Cache (VGC) entry corresponding to the volume id
and the parent id of the removed volume header.
The volume parent id is unknown to the volume server when removing a
volume disk header on behalf of a "vos zap -force" operation. In this
case, the volume server issues a fssync query to attempt look up to the
parent id from the file server's VGC. If this fssync query fails for
some reason, volume server is unable to delete the VGC entry for the
deleted volume header. The volume server logs an error and vos zap
reports a undocumented error code.
One common way this can be encountered is to issue a "vos zap -force" on
a file server that has just been restarted. In this case, the VGC may
not be fully populated yet, so the volume server is not able to look up
the parent id of the given volume.
With this commit, relax the requirement for the parent id when deleting
VGC entries. A placeholder of 0 is used to mean any parent id for the
given volume id.
This obviates the need to query for the parent id when performing a "vos
zap -force", and allows the volume server to remove any VGC entries
associated with the volume id being zapped.
Reviewed-on: https://gerrit.openafs.org/12839 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 65b55bcc26f69f25c67518f672b34be73f3be370)
Change-Id: I2e927d7b388c7be36a67e196a3acb70e58c9a661
Reviewed-on: https://gerrit.openafs.org/13896 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Yadavendra Yadav <yadayada@in.ibm.com> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Marcio Barbosa [Mon, 6 Jun 2016 17:03:54 +0000 (14:03 -0300)]
sys: retry lsetpag if errno is EINTR
The variable errno might be set by some system calls to indicate the
reason why the system call in question did not work as expected. If the
setpag system call is interrupted by a signal, the value of errno will
be EINTR. This value means that setpag did not succeed because it was
interrupted.
If lsetpag did not succeed and errno is equal to EINTR, try again.
Reviewed-on: https://gerrit.openafs.org/12295 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 2ae2a15c9dc9b26eaa15964cc96fdeeb6d82c74c)
Change-Id: I58d4aa633e5cadea2bc7b222f68306f07657b754
Reviewed-on: https://gerrit.openafs.org/13975 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Marcio Barbosa [Thu, 7 Nov 2019 03:10:12 +0000 (00:10 -0300)]
afs: afs_pag_wait() makes process unkillable
To enforce a maximum average rate of one PAG allocation per second,
afs_pag_wait(), called by afs_setpag*(), sleeps until the difference
between the current time and pag_epoch gets greater than pagCounter.
Unfortunately, this function ignores the code returned by afs_osi_Wait().
As a result, it is not possible to kill the process that requested the
new pag while afs_pag_wait() is sleeping.
To fix this problem, do not ignore the code returned by afs_osi_Wait().
Reviewed-on: https://gerrit.openafs.org/12260 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 9563807791e2402f7a214a90e96cf6ed8ea5abfb)
Change-Id: Id2453d6eb2b6cc973082da28bb3746c9f9c5ddb2
Reviewed-on: https://gerrit.openafs.org/13974 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
afs: avoid extra VL_GetEntryByName for .readonly's
In the VLDB, there's only one logical entry for a volume and its
associated clones; there are not separate entries for the RW volume
"avol", the RO volume "avol.readonly", and the BK volume
"avol.backup". And so, when looking up a volume in the VLDB by name,
the vlserver ignores any trailing ".readonly" or ".backup" in the
given name. More concretely, the result of calling
VL_GetEntryByName*("avol") is identical to that from calling
VL_GetEntryByName*("avol.readonly").
Accordingly, if afs_GetVolumeByName(name) failed because the volume
was not found in the VLDB, afs_GetVolumeByName(name.readonly) will
fail as well (barring a change in external circumstances, such as the
volume being created or a network connection coming back up).
Therefore, the extra call in EvalMountData() is not necessary and can
be removed.
Remove the extra call, to slightly improve the response time of the
client if the volume in question does not exist, and to reduce
vlserver load when patched clients are looking up nonexistent volumes.
Michael Meffie [Fri, 4 Apr 2014 14:27:10 +0000 (10:27 -0400)]
cmd: improve help for programs without subcommands
Some programs do not have subcommands (other than the standard "help",
and "version" subcommands). The cmd library provides the "noopcode"
mechanism for new subcommand-less programs, but older programs take
advantage of the optional "initcmd" token to simulate subcommand-less
programs. The "initcmd" token is optional to run the command, however
it is required to display the command help.
For example, running the xstat_cm_test program without any options gives
a syntax error:
Retrying with -help (or help, -h, --help), gives the rather unhelpful
output:
$ xstat_cm_test -help
xstat_cm_test: Commands are:
apropos search by help text
help get help on commands
initcmd initialize the program
It is not obvious to the user how to get the command usage for the
program, nor that the initcmd subcommand to "initialize the program" is
actually is a placeholder to run the program.
Instead, display the command usage when help is requested and initcmd is
the only defined subcommand for a program.
For example:
$ xstat_cm_test -help
Usage: src/xstat/xstat_cm_test [initcmd]
-cmname <Cache Manager name(s) to monitor>+
-collID <Collection(s) to fetch>+ [-onceonly]
[-frequency <poll frequency, in seconds>]
[-period <data collection time, in minutes>] [-debug] [-help]
Where: -onceonly Collect results exactly once, then quit
-debug turn on debugging output
The libcmd library now supports an "noopcode", which should used for
future subcommand-less programs, but converting old programs to remove
the initcmd opcode could break scripts which actually specify the
optional initcmd token.
This commit adds a new libcmd flag called CMD_IMPLICIT which is used to
denote built-in subcommands such as "version" and "help".
Reviewed-on: https://gerrit.openafs.org/10983 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 77ae3dc899e89f327328c874628f100a765846c4)
Change-Id: I5b31f12f844f14e6cf31ee28c1eb60c98fcf4b59
Reviewed-on: https://gerrit.openafs.org/13894 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Cheyenne Wills [Fri, 2 Aug 2019 16:31:13 +0000 (10:31 -0600)]
restorevol: replace snprintf with asprintf
GCC is generating format-truncations warnings. With newer levels of gcc
(e.g. gcc8) and --checking-enabled these warnings result in errors and
failed builds. In addition clang8 static analysis tools are reporting
memory leaks.
Replace snprintf with asprintf and eliminate some of the large work
buffers that are being placed on the stack. In order to correct some of
the format-truncation errors the size of the buffers grew significantly
(e.g. gcc is reporting the need to resize some of the buffers from 256
bytes to 4K in order to eliminate the warnings).
Ensure allocated work buffers are freed before function return.
Obtained a clean build with gcc9/clang8 with --enable-checking and a
clean scan-build report with clang8.
Reviewed-on: https://gerrit.openafs.org/13494 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit bf24b301a10dcb5710a98e58252213bd72c6f352)
Change-Id: If9fa37613841ffd090ec565dc24171bf89579c5b
Reviewed-on: https://gerrit.openafs.org/13750 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Cheyenne Wills [Fri, 1 Mar 2019 15:46:32 +0000 (08:46 -0700)]
bos: remove smail-notifier
smail-notifier is a sample program that is undocumented and has not
been well maintained. It produces copious compiler warnings, and
would require effort to bring the code up to decent coding practices.
The bosserver provides a -notifier feature that can be used for
notifications, but that feature does not depend on this sample program.
Removed the code, cleaned up the Makefiles and .gitignore.
Reviewed-on: https://gerrit.openafs.org/13509 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 6e988a5b3900fe73c314c9960d6fb7753ff98411)
Change-Id: I073a2b772f894e321bd0b41e012229c8e6d3105c
Reviewed-on: https://gerrit.openafs.org/13738 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Cheyenne Wills [Tue, 1 Oct 2019 18:14:41 +0000 (12:14 -0600)]
LINUX 5.3: Add comments for fallthrough switch cases
With commit 6e0f1c3b45102e7644d25cf34395ca980414317f (LINUX: Honor
--enable-checking for libafs) building libafs against a linux 5.3
kernel compiles with errors due to fall through in case statements when
--enable-checking / --enable-warning is used.
e.g.
src/opr/jhash.h:82:17: error: this statement may fall through
[-Werror=implicit-fallthrough=]
case 3 : c+=k[2];
~^~~~~~
The GCC compiler will disable the implicit-fallthrough check for case
statements that contain a "special" comment ( /* fall through */ ).
Add the 'fall through' comment to indicate where fall throughs are
acceptable.
This commit only adds comments and does not alter any executable code.
The -Wimplicit-fallthrough flag was enabled globally in the linux kernel
build in 5.3-rc2 (commit: a035d552a93bb9ef6048733bb9f2a0dc857ff869
Makefile: Globally enable fall-through warning)
Reviewed-on: https://gerrit.openafs.org/13881 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit a455452d7ee98d160620925bb8a0e3d0f4dfd7ec)
Andrew Deason [Wed, 3 Jul 2019 17:55:53 +0000 (12:55 -0500)]
LINUX: Unlock page on afs_linux_read_cache errors
When afs_linux_read_cache is called with a non-NULL task, it is
responsible for unlocking 'page' (unless it's unlocked in a background
task), even if we encounter an error. Currently we almost always do
unlock the given page for a non-NULL task, but if we manage to hit one
of the codepaths that 'goto out', we skip over the unlock_page() call
near the end of the function, and the page never gets unlocked.
As a result, the page stays locked forever. That generally means any
future access to the same file will block forever, and when we try to
flush the relevant vcache, we will block waiting for the page lock
while holding GLOCK. (This can happen via the background daemon via
e.g. afs_ShakeLooseVCaches -> osi_TryEvictVCache -> afs_FlushVCache ->
osi_VM_FlushVCache -> vmtruncate -> ... -> truncate_inode_pages_range
-> __lock_page on Linux 2.6.32-754.2.1.el6.) This quickly brings the
whole client to a halt until the machine can be forcibly rebooted.
To solve this, just move the 'out:' label to before the page unlock.
Add a few locking-related comments around the relevant code to help
explain some relevant details.
The relevant code has changed and been refactored over the years, but
this problem has probably existed ever since this code was originally
converted to using the readpage() of the underlying cache fs, in
commit 88a03758 (Use readpage, not read for fastpath access).
Reviewed-on: https://gerrit.openafs.org/13672 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit eed79e2d28dcab889d01869e57dec14fd30d421c)
LINUX: Avoid re-taking global lock in afs_dentry_iput
“dput” function internally can call dentry_iput which results in
calling afs_dentry_iput. So in case before calling “dput” if global lock
was held then when afs_dentry_iput is called it will again try to lock
global lock and will result in deadlock scenario. So to avoid this
deadlock make sure if global lock is already taken before calling
afs_dentry_iput, don’t try to lock it again. This issue was partially
fixed in commit 0dac4de8 (Linux: drop GLOCK before calling dput)
Reviewed-on: https://gerrit.openafs.org/13725 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 5792e0211be275cf79d10e8c5f6ab2a14493e07a)
Change-Id: I4a17700adb18956fc61462663fdb690b267cc928
Reviewed-on: https://gerrit.openafs.org/13748 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Mon, 1 Oct 2018 15:56:53 +0000 (11:56 -0400)]
afs: Free 'addrs' array
Currently, 3 places in libafs allocate an 'addrs' array in a very
similar way to loop through our list of servers:
ForceAllNewConnections(), afs_LoopServers(), and PCallBackAddr(). Of
these, only afs_LoopServers actually frees the array.
ForceAllNewConnections and PCallBackAddr leak the memory, but these
are only hit from infrequent pioctls that can only be run by root, so
the impact is small.
Fix ForceAllNewConnections and PCallBackAddr to free the array.
Reviewed-on: https://gerrit.openafs.org/13355 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 0548ee436d0f0f92a980d22e03149faedf38dc70)
Change-Id: I5d64899c7be40ba3e1b0985c4829933eebbd8323
Reviewed-on: https://gerrit.openafs.org/13899 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Thu, 26 Sep 2019 18:35:51 +0000 (13:35 -0500)]
rx: Fix test for end of call queue for LWP
Commit 6ad3d646 (rx: Correctly test for end of call queue) fixed a
broken end-of-queue check in rx_GetCall, but it only fixed the
RX_ENABLE_LOCKS version of rx_GetCall. The non-locks version (i.e. the
LWP version) still had this bug. Fix it for the LWP case, to avoid
some rare cases where an Rx call can get stuck in the incoming queue.
Also remove the comment added by commit 170dbb3c (rx: Use opr queues),
since we're fixing the mentioned problem.
Reviewed-on: https://gerrit.openafs.org/13880 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit d9fc4890f01a41fa5a63f97f2446b3afc35b473f)
Change-Id: I2e0106b63a8bf09634500944490dfae2e86c18b9
Reviewed-on: https://gerrit.openafs.org/13892 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Benjamin Kaduk [Fri, 9 Aug 2019 14:59:44 +0000 (07:59 -0700)]
The interminable rework of afs_random()
Commit f0a3d477d6109697645cfdcc17617b502349d91b restructured the
operation on tv_usec to avoid using undefined behavior, but in
the process introduced a behavior change. Historically (at least as
far back as AFS-3.3), we masked off the low nybble (four bits) of
tv_usec before adding the low byte (eight bits) of the rxi_getaddr()
output. Why there was a desire to combine two sources of input for
the overlapping four bits remains unclear, but restore the historical
behavior for now, as the intent of commit f0a3d477d6109697645cfdcc17617b502349d91b was to not introduce any
behavior changes.
Reviewed-on: https://gerrit.openafs.org/13759 Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 1c4e94da2a8fce9d79006ad6d6673d3d7de117d3)
Change-Id: Iec10673e5ec73c1e0edcc231690cb6133fce8691
Reviewed-on: https://gerrit.openafs.org/13879 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>
Benjamin Kaduk [Sun, 3 Feb 2019 01:45:31 +0000 (19:45 -0600)]
rework afs_random() yet again
clang 7 notes that ~0 is signed and that left-shifting into the sign
bit is undefined behvaior. Use a new construction to clear the low
byte of tv_usec with only bitwise operations that are independent of
the width of tv_usec and stay within the realm of C's defined behavior.
Reviewed-on: https://gerrit.openafs.org/13474 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit f0a3d477d6109697645cfdcc17617b502349d91b)
Change-Id: I4f0438c2fc8237968f41409ca23ac098839508fe
Reviewed-on: https://gerrit.openafs.org/13743 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>
Benjamin Kaduk [Sun, 3 Feb 2019 00:39:53 +0000 (18:39 -0600)]
Avoid incomplete function type in casts
clang complains that these casts contain an incomplete function type
(since the function argument is omitted rather than declared to be
void). Since we just need the cast to pointer type, let the compiler
do it implicitly and pass stock NULL, rather than trying to force a
cast to function-pointer type.
Reviewed-on: https://gerrit.openafs.org/13473 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 96c0b88947c7aab605170bdca633d3716051a58e)
Change-Id: I950ff8de925a1ca03e50ad7ec394123445b5ce4a
Reviewed-on: https://gerrit.openafs.org/13742 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Fri, 1 Feb 2019 22:31:50 +0000 (16:31 -0600)]
Avoid calling krb5_free_context(NULL)
Several places in the code currently call krb5_free_context(ctx) in a
cleanup code path, where 'ctx' may or may not be NULL. This is not
guaranteed to be okay, so check for NULL to make sure we don't cause
issues in these code paths.
While we are here cleaning up krb5_free_context() calls, also fix a
few call sites in afscp_util.c that were not calling krb5_free_context
in all error paths.
Reviewed-on: https://gerrit.openafs.org/13461 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 26b1dc036719a588a5cadecb14053bd4079c1f48)
Change-Id: I3b0d22f51f4fe85897116b7f96d096570258eed2
Reviewed-on: https://gerrit.openafs.org/13902 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Cheyenne Wills [Fri, 9 Aug 2019 19:25:26 +0000 (13:25 -0600)]
vlserver: initialize nvlentry elements after read
Commit 7620bd33487207b348ed7aeba45f8d743132ba84 (vlserver: fix
vlentryread() for old vldb formats) leaves the tail end of the
serverNumber, serverParition and serverFlags arrays uninitialized since
it only copies OMAXNSERVERS elements into arrays that have NMAXNSERVERS
elements.
Initialize the elements in the nvlentry server arrays that were not
copied with BADSERVERID.
Reviewed-on: https://gerrit.openafs.org/13755 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit ddf7d2a7f4bfdcab238e791cb8c49bb803e76b09)
Change-Id: I4e1065bedda0f50b85cf472d015f2c86e4af82c8
Reviewed-on: https://gerrit.openafs.org/13846 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Benjamin Kaduk [Sat, 2 Feb 2019 20:23:03 +0000 (14:23 -0600)]
vlserver: fix vlentryread() for old vldb formats
When we're using old format compatibility, use OMAXNSERVERS for the
array lengths instead of MAXNSERVERS. Otherwise we'll try to copy more
data than we've read.
Detected by gcc8 as:
vlutils.c:183:2: error: ‘memcpy’ forming offset [149, 151] is out of the bounds [0, 148] of object ‘tentry’ with type ‘struct vlentry’ [-Werror=array-bounds]
memcpy(nbufp->serverFlags, oep->serverFlags, NMAXNSERVERS);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
vlutils.c:141:26: note: ‘tentry’ declared here
struct vlentry *oep, tentry;
^~~~~~
Reviewed-on: https://gerrit.openafs.org/13465 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 7620bd33487207b348ed7aeba45f8d743132ba84)
Change-Id: I7dc4ad48805c6a82dd021d156fe187dd97e5b456
Reviewed-on: https://gerrit.openafs.org/13734 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
GCC 9 introduced new warnings/errors and is flagging a sprintf with a
format-overflow warning. With --checking-enabled, this error is causing
uss_procs.c to fail during compile.
A file name with the full path is being composed and the size of the
buffer was triggering a possible format-overflow warning/error.
Use asprintf to allocate the buffer dynamically instead of using a
buffer sitting on the stack (reducing the stack requirements by 2K).
Produces new error message if asprintf returns an error.
Reviewed-on: https://gerrit.openafs.org/13664 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 41ee558329560bce037ad2860282d8b49aa11b2d)
Change-Id: I5c5866142ae17c92017201fb567f847b5c2907a0
Reviewed-on: https://gerrit.openafs.org/13729 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
GCC 9 introduced new warnings/errors and is flagging a sprintf with a
format-overflow warning. With --checking-enabled, this error is causing
testpt.c to fail during compile.
Change the buffer size from 16 bytes to PR_MAXNAMELEN+1 and use snprintf
instead of sprintf. Generate an error message and exit if snprintf
truncates the string.
Reviewed-on: https://gerrit.openafs.org/13663 Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 4a57cc54dfb6789a86ee735360ee44209c1a901a)
Change-Id: I2f8012e7fb4384f3ad877d2c9beb5f00b03716b8
Reviewed-on: https://gerrit.openafs.org/13730 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Cheyenne Wills [Tue, 25 Jun 2019 21:39:40 +0000 (15:39 -0600)]
ptserver: Incorrect variable used to print error msg
In testpt.c the variable cdir is used to print the name of the temporary
dir. However at this point in the code cdir is NULL and the variable
tmp_conf_dir contains the actual name that should be used in the error
message.
Flagged as an error when --enable-checking is on and using GCC 9.
Reviewed-on: https://gerrit.openafs.org/13662 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit f938f5f248a3cb3f7ac871f5ef45a0e2d043706b)
Change-Id: I1b993ddc2545f90736811e2eb85ba4b3bae6e657
Reviewed-on: https://gerrit.openafs.org/13728 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Benjamin Kaduk [Fri, 12 Jul 2019 04:07:35 +0000 (21:07 -0700)]
aklog: require opt-in to enable single-DES in libkrb5
Since the introduction of rxkad-k5 in response to OPENAFS-SA-2013-003,
it is not strictly necessary to configure libkrb5 to allow weak crypto
in order to obtain an AFS token. A sufficient amount of time has passed
since then that it is safe to assume that the default behavior is the
more-secure one, and require opt-in for the insecure behavior.
To indicate that the use of single-DES is quite risky, add the
"-insecure_des" argument to both klog and aklog, to gate the
preexisting calls that enable weak crypto/single-DES.
These calls, and the -insecure_des option, may be removed entirely
in a future commit.
Reviewed-on: https://gerrit.openafs.org/13689 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit eaae6eba8ca10ba7a5a20ee0d1b5f91bc2bac6c6)
Change-Id: I197042e12567fa0fed1b6584e85c3f0a520efa4c
Reviewed-on: https://gerrit.openafs.org/13791 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>
GCC 7 is producing new warnings due to better compile time analysis.
With --enable-checking v5der.c is failing with 2 errors due to possible
format-truncation in some snprintf calls. The format strings are being
used to format a date and time values from a tm structure.
The actual warnings/errors are being triggered from arithmetic being
performed on the year and month members of the structure. The resulting
values should not exceed the format lengths, but the compilers are still
flagging the statements.
v5der.c is part of the heimdal package that is pulled into the openafs
source tree. v5der.c is not compiled directly but is #included in
ticket5.c
Update ticket5.c to change the severity of the format-truncation
diagnostic to a warning if using GCC 7 (or higher).
Note: since v5der.c is pulled from an external source (heimdal), any
changes to update v5der.c directly would need to be performed upstream.
Reviewed-on: https://gerrit.openafs.org/13661 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 98ca332c4a5ac9e5687fb4fe21b350134bc74d1b)
Change-Id: I1a808060b302549887e529e74bc3805d9431c499
Reviewed-on: https://gerrit.openafs.org/13727 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Stephan Wiesand [Fri, 6 Sep 2019 11:35:02 +0000 (13:35 +0200)]
ptserver: Increase length limit of namelist, idlist, prlist, prentries
An implementation limit of those lists was introduced in commit a0ffea098d8c5c5b46c6bf86a12d28d6e7096685 to prevent using unlimited
amounts of memory in ptserver and the client. Subsequent reports
indicate that the chosen limits are small enough to restrict
functionality currently in use at some sites where membership lists
exceed the current limit. Since this is just an implementation-
defined limit and can freely change from release to release, increase
the threshold by an order of magnitude to preserve functionality for
existing deployments while still retaining some protection against
attacker-controlled excessive memory allocation.
Reviewed-on: https://gerrit.openafs.org/13838 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit d1e90b82ebb2685cbac3ecb3fd99136328b35357)
Change-Id: Ifa229179ad6d2962a8d49df6abd1add94fad7259
Reviewed-on: https://gerrit.openafs.org/13844 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>
Andrew Deason [Tue, 27 Aug 2019 01:33:58 +0000 (20:33 -0500)]
WINNT: Link tbutc against mtafsutil.lib
tbutc uses pthreads, not LWP, so link it against mtafsutil.lib (a
pthread library), and not afsutil.lib (an LWP library).
Reviewed-on: https://gerrit.openafs.org/13822 Tested-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 7a76f4dc00984d42b0535a8edbedee034ada896f)
Change-Id: I133fff53d1974658ed1fe95e48abd9779a346a4f
Reviewed-on: https://gerrit.openafs.org/13852 Reviewed-by: Andrew Deason <adeason@sinenomine.net> 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>
Andrew Deason [Tue, 27 Aug 2019 00:34:19 +0000 (19:34 -0500)]
rx: Export rx_GetCallStatus
Commit 59d3a8b8 (vos: restore status information to 'vos status')
added the function rx_GetCallStatus to Rx, and used it in the
volserver, but didn't add the function to our .sym and .exp files,
causing a linker error on at least WINNT.
Add the function to the relevant .sym/.exp files, so we can link on
all platforms.
Change-Id: I859ac6d04d8a21eb6f8b4ba3f3720ca318e91334
Reviewed-on: https://gerrit.openafs.org/13820 Tested-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit c3716b3d7e32f47b084657e163b029e9f1756fa4)
Reviewed-on: https://gerrit.openafs.org/13851 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Mon, 26 Aug 2019 23:14:48 +0000 (18:14 -0500)]
WINNT: Link butc against audit
Since commit c43169fd (OPENAFS-SA-2018-001 Add auditing to butc server
RPC implementations), butc references symbols from audit. So add audit
to our libraries to link against, so we can link butc on WINNT.
Reviewed-on: https://gerrit.openafs.org/13818 Tested-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit e4b689e8c7cb39b72854dd38b6a92134591c8bca)
Change-Id: Ib27755730178afbbd85e3aad265c1f956b3785ef
Reviewed-on: https://gerrit.openafs.org/13850 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Tue, 5 Nov 2019 16:50:01 +0000 (10:50 -0600)]
afs: Avoid giving wrong 'tf' to afs_InitVolSlot
Commit 75e3a589 (libafs: afs_InitVolSlot function) split out a bit of
our code that initializes a struct volume into the afs_InitVolSlot
function. However, it caused us to almost always pass a non-NULL 'tf'
to afs_InitVolSlot, even if the target volume was not found.
That is, before that commit, our code roughly did this:
The reason for the extra 'j != 0' check after the loop is to see if we
hit the end of the volume hash chain, or if we actually found a
matching 'tf' in the loop.
And after that commit, the code did this:
for (...; j != 0; j = tf->next) {
...;
if (j != 0) {
tf = &staticVolume;
if (tf->volume == volid)
break;
}
}
if (tf) {
use_tf_data();
} else {
use_blank_data();
}
The check for 'j != 0' was moved to inside the for loop, but 'j' is
always nonzero in the loop (otherwise, the for() would exit the loop).
This means that if we didn't find a matching 'tf' in the loop, our
'tf' would be non-NULL anyway, and so we'd initialize our volume slot
from just the last entry in the hash chain.
This means that for volumes that are not found in the VolumeItems
file, our struct volume will probably be initialized with arbitrary
data from another volume, instead of being initialized to the normal
defaults (the 'else' clause in afs_InitVolSlot).
This means that the 'dotdot' entry for the volume may be wrong, and so
we may report the wrong parent dir for the root of a volume. However,
the 'dotdot' entry should be fixed when the volume root is accessed
via a mountpoint, so any such issue should be temporary. And of
course, on some platforms (LINUX) we don't ever use the 'dotdot'
information for a volume, and even on other platforms, often resolving
the '..' entry is handled by other means (e.g. shells often calculate
it themselves). But some 'pwd' calculations and other '..' corner
cases may be affected.
To fix this, change the relevant loop so that we only set 'tf' to
non-NULL when we actually find a matching entry.
Reviewed-on: https://gerrit.openafs.org/13933 Tested-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 4a9078c6bbf51720a5eacf7e6ba21443e5103eee)
Change-Id: Ib1e7519db8f844872c4b88b54978f358ff7b299e
Reviewed-on: https://gerrit.openafs.org/13937 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Mark Vitale [Tue, 17 Sep 2019 19:14:44 +0000 (15:14 -0400)]
viced: consistently enforce host thread quota for ICBS(3)
From time to time, the fileserver may issue potentially long-running
RXAFSCB_* RPCs back to a host (client). If these are holding h_Lock_r
(host->lock) while running, they may cause other service threads for the
same host (client) to block.
In order to prevent a given host from tying up too many service threads
in this way, the fileserver enforces a quota limiting how many threads
can be waiting for h_Lock_r on a particular host while waiting for one
of the following RPCs to complete:
- RXAFSCB_TellMeABoutYourself (TMAY)
- RXAFSCB_WhoAreYou
- RXAFSCB_ProbeUuid
- RXAFSCB_InitCallBackState (ICBS)
- RXAFSCB_InitCallBackState3 (ICBS3)
Note: Although some of these RPCs are relatively lightweight, they may
still experience network delays.
This quota is enforced by calling h_threadquota() in h_Lookup_r and
h_GetHost_r. The quota check is enabled for a given host by turning on
host->hostFlags HWHO_INPROGRESS for the duration of the RXAFSCB_* RPC.
The quota check is only needed, and should only be enabled, when the RPC
is issued while h_Lock_r is held.
However, there are a few paths to ICBS(3) where h_Lock_r is held but
HWHO_INPROGRESS is not set. A delay in those paths may allow a host to
consume an unlimited number of fileserver threads. One such path
observed in a field report was SRXAFS_FetchStatus -> CallPreamble ->
BreakDelayedCallBacks_r -> RXAFSCB_ICBS3.
Instead, enable host thread quotas for all remaining unregulated ICBS(3)
RPCs.
Reviewed-on: https://gerrit.openafs.org/13873 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit aefc4c4f46e13f59b4cbe043e1a2a6f4ed99e076)
Change-Id: If3883a152078bba9995e0c8a13ab31788db6347f
Reviewed-on: https://gerrit.openafs.org/13893 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> Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Mon, 26 Aug 2019 21:08:31 +0000 (16:08 -0500)]
kauth: Move COUNT_REQ to beginning of block
Commit b604ee7a (OPENAFS-SA-2018-002 kaserver: prevent KAM_ListEntry
information leak) added a memset in kamListEntry before COUNT_REQ, but
COUNT_REQ declares a local variable. This breaks the WINNT build,
because we must declare variables at the beginning of a block.
To fix this, just swap the two lines.
Reviewed-on: https://gerrit.openafs.org/13815 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit b9b5385e6a04dcacd180f33e39495c7909fe4df3)
Change-Id: Id9c1fd67e4614f8f433415486e107ecb4bd0d708
Reviewed-on: https://gerrit.openafs.org/13849 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Mon, 26 Aug 2019 18:13:28 +0000 (13:13 -0500)]
WINNT: Build bubasics before audit
Commit 9ebff4c6 (OPENAFS-SA-2018-001 audit: support butc types) made
src/audit require the butc.h header, and updated Makefile.in to
reflect this. However, this dir is also built on WINNT, and the
NTMakefile was not updated to reflect this dependency. As a result, we
might fail to build src/audit on WINNT, since butc.h may not exist
yet, and we get an error like:
cl [...] /c audit.c
audit.c
cl : Command line warning D9025 : overriding '/W4' with '/W3'
audit.c(27) : fatal error C1083: Cannot open include file: 'afs/butc.h': No such file or directory
NMAKE : fatal error U1077: 'C:\PROGRA~2\MICROS~1.0\VC\bin\amd64\cl.EXE' : return code '0x2'
To fix this, move 'bubasics' to be made before 'audit' in NTMakefile,
so butc.h is available when we build 'audit'.
Reviewed-on: https://gerrit.openafs.org/13813 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 9eeb3ec09f5421ceab2be415a193bb3a3c44925f)
Change-Id: If36de5664ea0eb7208810c224d30092f0a4d1745
Reviewed-on: https://gerrit.openafs.org/13848 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Mon, 8 Jul 2019 19:49:23 +0000 (14:49 -0500)]
afs: Avoid panics in afs_InvalidateAllSegments
Currently, afs_InvalidateAllSegments panics when afs_GetValidDSlot
fails. We panic in these cases because afs_InvalidateAllSegments
cannot simply return an error to its callers; we must invalidate all
segments for the given vcache, or we risk serving incorrect data to
userspace as explained in the comments.
Instead of panicing, though, we could simply sleep and retry the
operation until it succeeds. Implement this, retrying every 10
seconds, and logging a message every hour that we're stuck (in case
we're stuck for a long time).
When we retry the operation, do so in a background request, to avoid a
somewhat common situation on Linux where we always get I/O errors from
the cache when the calling process has a SIGKILL pending. Create a new
background op for this, BOP_INVALIDATE_SEGMENTS.
With this, the relevant vcache will be effectively unusable for the
entire time we're stuck in this situation (avc->lock will be
write-locked), but this is at least better than panicing the whole
machine.
Reviewed-on: https://gerrit.openafs.org/13677 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 3be5880d1d2a0aef6600047ed43d602949cd5f4d)
Change-Id: Iba1cde70a4d5e919fedfe27d0540878113a369e4
Reviewed-on: https://gerrit.openafs.org/13847 Tested-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@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>
clang complains that these casts contain an incomplete function type
(since the function argument is omitted rather than declared to be
void). Since we just need the cast to pointer type, let the compiler
do it implicitly and pass stock NULL, rather than trying to force a
cast to function-pointer type.
Reviewed-on: https://gerrit.openafs.org/13726 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit d6262c3f391e4176bec207fd0e8d4d6091a7f4e2)
Change-Id: I4544c37591bb68ff6bbe345192490bb79c843fc5
Reviewed-on: https://gerrit.openafs.org/13749 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Benjamin Kaduk [Sun, 3 Feb 2019 01:52:26 +0000 (19:52 -0600)]
libadmin: appease clang -Wsometimes-uninitialized
clang thinks that 'time' can be used uninitialized:
bos.c:1472:9: error: variable 'time' is used uninitialized whenever 'if' condition is
false [-Werror,-Wsometimes-uninitialized]
if (as->parms[TIME].items) {
^~~~~~~~~~~~~~~~~~~~~
bos.c:1478:57: note: uninitialized use occurs here
if (!bos_ExecutableRestartTimeSet(bos_server, type, time, &st)) {
^~~~
bos.c:1472:5: note: remove the 'if' if its condition is always true
if (as->parms[TIME].items) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~
bos.c:1445:5: note: variable 'time' is declared here
bos_RestartTime_t time;
^
but in this command description, the TIME argument is required.
Add a never-triggered error exit to appease the compiler when
--enable-checking is activated.
Reviewed-on: https://gerrit.openafs.org/13476 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 453060c27a5d33d3c27128d169298f9d66d06f1a)
Change-Id: Iac80d4ec7c2a33dcb470de2daedf693c20b96b00
Reviewed-on: https://gerrit.openafs.org/13745 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Benjamin Kaduk [Sun, 3 Feb 2019 01:48:20 +0000 (19:48 -0600)]
uss: signed/unsigned char fallout
When char is signed, assigning 255 to a variable of type char changes
the value, which causes clang to emit a warning and fail the
--enable-checking build.
Reviewed-on: https://gerrit.openafs.org/13475 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 7c15e6efe62fb3fe1970c56331df09b257abf6d9)
Change-Id: I3dd374582b57e46460ea80ead75913948c2d2262
Reviewed-on: https://gerrit.openafs.org/13744 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Benjamin Kaduk [Sat, 2 Feb 2019 23:10:29 +0000 (17:10 -0600)]
dumpscan: appease gcc8 -Wformat-overflow
gcc does not benefit from our external knowledge that tm_year is
tightly bounded, and thinks it could still be in the range
[-2147481748, 2147483647], which would overflow our string buffer.
The function in question does not have error handling in place, so
rather than adding some or trying to assert the proper bounds, just
use a slightly larger buffer for safety.
Reviewed-on: https://gerrit.openafs.org/13472 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 8f03ff3bdd8eb9f4557cdb7054aee9b8ea432160)
Change-Id: I05c8d998c6d40118a1bde923e346cddbdfa4192b
Reviewed-on: https://gerrit.openafs.org/13741 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Benjamin Kaduk [Sat, 2 Feb 2019 23:02:08 +0000 (17:02 -0600)]
scout: band-aid -Wformat-truncation
gcc8 gets pretty confused about the bounds on these things (presumably
due to our alignment options) and thinks this could potentially be a huge
string. Check for truncation to appease the compiler, instead of trying
to ensure that the buffer is big enough.
Reviewed-on: https://gerrit.openafs.org/13470 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Cheyenne Wills <cwills@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 df8534909fdc1fa8417aa788c0fa71c5dbe7eb30)
Change-Id: Idf3a2f32ba4630a7d11b2c0664c6dd9b694eb7db
Reviewed-on: https://gerrit.openafs.org/13739 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Benjamin Kaduk [Sat, 2 Feb 2019 20:43:04 +0000 (14:43 -0600)]
vlserver: use large enough buffer for rxinfo string
The "[dotted-quad] rxkad:name.inst@cell" construct can be as large as
(3*4+3)+7+3*64+2+1 == 217 characters (including trailing NUL); size
our buffer accordingly to avoid the risk of truncation.
Reviewed-on: https://gerrit.openafs.org/13466 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 584b0f2b6b4391c0c879352bb1786c0f267666c9)
Change-Id: Ia11e685ec17f34a9a8fdc42d392b8a2677f63696
Reviewed-on: https://gerrit.openafs.org/13735 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
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)
Change-Id: I634ddb27e7a8dbe5c9d1dacdc83070efa470b50b
Reviewed-on: https://gerrit.openafs.org/13918 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: Benjamin Kaduk <kaduk@mit.edu>
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:
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:
Andrew Deason [Wed, 17 Oct 2018 21:35:36 +0000 (16:35 -0500)]
Remove one more automake VERSION reference
The configure summary was still referencing the old automake-specific
VERSION var. Use the autoconf PACKAGE_VERSION var instead, so this
actually shows our version.
Reviewed-on: https://gerrit.openafs.org/13360 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 0f65b40b24599d58cf30bfd47fae83ab54e1416a)
Change-Id: I5bd9399acc6e4c6dd19b94198354b600f35bee15
Reviewed-on: https://gerrit.openafs.org/13790 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Thu, 11 Oct 2018 05:18:17 +0000 (00:18 -0500)]
Remove automake autoconf vars
Commit 4706854f (autoconf: updates and cleanup) removed our invocation
of AM_INIT_AUTOMAKE, which defines the output variables PACKAGE and
VERSION. Several files in our build system are still referencing
@PACKAGE@ and @VERSION@, though, leaving them un-substituted. This
most easily is seen as the AFSVersion version string remaining as
"@VERSION@" when the tree is built without git, but it also affects
some packaging in the tree.
Remove references to @VERSION@ and @PACKAGE@, replacing them with
their autoconf equivalents @PACKAGE_VERSION@ and @PACKAGE_TARNAME@.
Reviewed-on: https://gerrit.openafs.org/13357 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 2f2c2ce62aa17ecac3651d64c1168af926f7458b)
Change-Id: If2b98b8930bc687170f53f852417fb9374bf6c60
Reviewed-on: https://gerrit.openafs.org/13789 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Cheyenne Wills [Fri, 9 Aug 2019 20:25:03 +0000 (14:25 -0600)]
LINUX 5.3.0: Use send_sig instead of force_sig
Linux 5.3.0 commit 3cf5d076fb4d48979f382bc9452765bf8b79e740 "signal
Remove task parameter from force_sig" (part of siginfo-linus branch)
changes the parameters for the Linux kernel function force_sig. See LKML
thread starting at https://lkml.org/lkml/2019/5/22/1351
According to the LKML discussion and the above commit message force_sig
is only safe to deliver a synchronous signal to the current task. To
send a signal to another task, we're supposed to use send_sig instead,
which has been available since at least linux 2.6.12-rc12.
Currently, rx_knet calls force_sig to kill the rxk_ListenerTask. With
the Linux 5.3.0 kernel, this module fails to compile due to the above
noted changes.
Replace the force_sig call with send_sig. In order to use send_sig, the
rxk_listener thread must allow SIGKILL and during shutdown (umount)
SIGKILL must be unblocked for the rxk_listener thread.
Note that SIGKILL is initially blocked on rxk_listener and is only
unblocked when shutting down the thread. Having the signal blocked is
sufficient to prevent unwanted signals from reaching the rxk_listener
thread during normal operation.
Reviewed-on: https://gerrit.openafs.org/13753 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 2b7af1243f46496c0b5973b3fa2a6396243f7613)
Change-Id: I6eb44311fbcc63adb6ebeb85a8e076922befd645
Reviewed-on: https://gerrit.openafs.org/13788 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Cheyenne Wills [Thu, 8 Aug 2019 22:53:13 +0000 (16:53 -0600)]
LINUX 5.3.0: Check for 'recurse' arg in keyring_search
Linux 5.3.0 commit dcf49dbc8077e278ddd1bc7298abc781496e8a08 "keys: Add a
'recurse' flag for keyring searches" adds a new parameter to
Linux kernel keyring_search function.
Update the call to keyring_search to include the recurse parameter if
available. Setting the parameter to true (1) maintains the current
search behavior.
Change-Id: I038117d1bccdf619a42132fba7d8d61b3ce3c14b
Reviewed-on: https://gerrit.openafs.org/13752 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-on: https://gerrit.openafs.org/13787 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
GCC 9 with --enable-checking produces a new warning/error in
afs_utilAdmin.c associated with a strcpy with the potential of an
overlap. The index used is signed which triggers the new warning. The
source and target of the strcpy are contained within the same higher
level structure.
Change the variable 'index' from signed to unsigned to resolve the
warning/error. Change the variable 'total' in the same structure to
unsigned to be consistent with it's usage with 'index'.
Reviewed-on: https://gerrit.openafs.org/13660 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 79dffe29c8a0ec55c4231a18077efdfa7c1edf53)
Change-Id: I19a192ecea86314851e6889274eb030c5caff8cb
Reviewed-on: https://gerrit.openafs.org/13724 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Tue, 30 Oct 2018 20:41:22 +0000 (15:41 -0500)]
aklog: Avoid misleading AFSCELL message
Currently, if the AFSCELL environment variable is set, aklog (and
other libauth-using utilities) print out a message when
afsconf_GetLocalCell is called:
Note: Operation is performed on cell env.example.com
However, this message is also printed (with the AFSCELL cell) when
aklog is given the -cell command-line argument, even though aklog
actually uses the cell given on the command line. For example:
$ AFSCELL=env.example.com aklog -cell cli.example.com -d
Note: Operation is performed on cell env.example.com
Authenticating to cell cli.example.com (server srv1.example.com).
[...]
libauth will normally not print the "Operation" message if we're not
using the default cell, but it determines this by checking if someone
called afsconf_GetCellInfo before calling afsconf_GetLocalCell. And
currently, aklog calls afsconf_GetLocalCell before
afsconf_GetCellInfo, so the message gets printed because libauth has
no way of knowing that we're actually using a different cell.
klog gets around this by making an additional ignored call to
afsconf_GetCellInfo before afsconf_GetLocalCell, but we can fix this
in aklog by just changing the order of the calls. So, just call
afsconf_GetCellInfo first; if we're using the local cell, we can just
give a NULL cell parameter, instead of looking up the local cellname
first.
Reviewed-on: https://gerrit.openafs.org/13371 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 877d9d79a32b9e81911cb567f844b11c693229f0)
Change-Id: I67350be8c25fb93975442175a64098123503b40c
Reviewed-on: https://gerrit.openafs.org/13676 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Mon, 25 Mar 2019 21:33:39 +0000 (16:33 -0500)]
afs: Avoid non-dir ENOENT errors in afs_lookup
Historically, there have been many subsystems in libafs that can
generate ENOENT errors for a variety of reasons. In addition to the
expected case where we lookup a name that doesn't exist, other
scenarios have caused ENOENT error codes to be generated, such as:
internal inconsistencies, I/O errors, or even abort codes from the
network.
When one of these scenarios cause an ENOENT error code in one of those
situations during afs_lookup() when the target name does actually
exist, it can be confusing to a user, or even result in incorrect
application behavior. On Linux in particular, ENOENT results from a
lookup are cached in negative dcache entries, and so can cause future
lookups for the same name to yield ENOENT errors.
Various commits have tried to avoid this abuse of the ENOENT error
code, such as 2aa4cb04 (afs: Stop abusing ENOENT). But we cannot
prevent receiving ENOENT abort codes from the network, and mistakes in
the future may cause more scenarios incorrectly yielding ENOENTs.
However, in afs_lookup, we do know that legitimate ENOENT errors can
only occur in one situation: when we have a valid directory blob, and the
afs_dir_Lookup() operation itself returns an ENOENT error for the
target name. For all other areas of afs_lookup(), we know that an
ENOENT error is not legitimate, since we may not be sure if the target
name exists or not.
So to proactively avoid incorrect ENOENT results, prevent afs_lookup
from returning ENOENT, except in the specific code path where
afs_dir_Lookup is called.
Reviewed-on: https://gerrit.openafs.org/13537 Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 5f48367f2bd5bf1c0e689c79508177b649b9113b)
Change-Id: I2698c26d7b75146d92e1763d49dce135ad66f672
Reviewed-on: https://gerrit.openafs.org/13692 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Mark Vitale [Thu, 23 May 2019 02:50:00 +0000 (22:50 -0400)]
auth: make PGetTokens2 work with 3-char cellnames
PGetTokens2 accepts two different types of input:
- an integer 'iterator' to request the nth token set for a user
- a string cellname to request the user's token set for that cell
Unfortunately, it distinguishes between these by assuming if the input
length is sizeof(afs_int32) (4 bytes), it must be an integer. This
assumption is incorrect if the cellname is three (3) characters long
plus a nul terminator.
The result is that the cellname string is interpreted as a very large
"n"; the subsequent search for the user's "very-large-nth-token" fails,
making it appear that the user has no valid token for this cell.
Improve on this heuristic by double-checking any putative integer input.
If it is actually a 3-character string, then process the input as a
cellname instead.
Andrew Deason [Sat, 3 Nov 2018 06:04:43 +0000 (01:04 -0500)]
ptserver: Check for -restricted in SPR_Delete
Currently, all prdb write operations, except for SPR_Delete, will fail
with PRPERM if called by a non-system:administrators caller while
restricted mode is active. SPR_Delete is missing this check, and so
is not affected by the -restricted option.
Fix this by inserting the same check for -restricted as all other code
paths that check for -restricted.
Reviewed-on: https://gerrit.openafs.org/13374 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit 2e556c0f23ae439c804352cf51fcf30878b03c7a)
Change-Id: I9a31cf4e6490aa13dc0c239d2660fc146553ee75
Reviewed-on: https://gerrit.openafs.org/13688 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Sat, 3 Nov 2018 05:58:58 +0000 (00:58 -0500)]
ptserver: Fix AccessOK -restricted for SYSADMINID
According to the documentation, as well as other code paths that check
for -restricted, the -restricted option does not affect members of
system:administrators. Currently, though, AccessOK only bypasses the
-restricted check if the caller is SYSADMINID itself (i.e. localauth).
Fix AccessOK to only do the -restricted checks if the caller is not in
system:administrators, to match the documentation as well as other
ptserver operations.
Reviewed-on: https://gerrit.openafs.org/13373 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 3a8fa4ecd65d5d743fdc573c9f0f261aee2063b6)
Change-Id: I786830efab229a50a521daf3efc624e949475030
Reviewed-on: https://gerrit.openafs.org/13687 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Tue, 30 Oct 2018 19:29:24 +0000 (14:29 -0500)]
ptserver: Fix AccessOK -restricted for addToGroup
The function AccessOK is used by all of ptserver RPC handlers that
need to do an authorization check, and the last two arguments are set
as such:
- When adding a member to a group, 'mem' is PRP_ADD_MEM and 'any' is
PRP_ADD_ANY
- When removing a member from a group, 'mem' is PRP_REMOVE_MEM and
'any' is 0
- When modifying an entry (setFieldsEntry) or modifying some global
database fields, 'mem' and 'any' are both set to 0
- When reading an entry and not modifying it, 'mem' and/or 'any' are
set to other values (depending on if we're checking membership,
examining the entry itself, etc)
Commit 93ece98c (ptserver-restricted-mode-20050415) added a check to
AccessOK to make it return false for -restricted mode when we are
adding a member to a group, or when 'mem' and 'any' are both 0. This
didn't catch the case when we are removing a member from a group,
though, when 'mem' is PRP_REMOVE_MEM.
It looks like commit a614a8d9 (ptutils-restricted-accessok-20081025)
tried to fix this by adding a check for PRP_REMOVE_MEM, but it also
required 'any' to be set to 0 for the conditional to succeed. This is
true when removing a member from a group, but when adding a member to
a group, 'any' is PRP_ADD_ANY, and so this check fails.
This means that currently, when restricted mode is turned on,
non-admins can still run addToGroup and setFieldsEntry successfully.
Fix this by checking for PRP_ADD_MEM/PRP_REMOVE_MEM separately from
checking if 'mem'/'any' are set to 0. Break up this conditional into
separate if() statements with comments to try to make the checks
more clear.
Reviewed-on: https://gerrit.openafs.org/13370 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit dfc78d533ef64c8d6daf134e2a0f67c5c16f7369)
Change-Id: I7f53570b42e2700a33dd5e72a31f6f7f8b876e79
Reviewed-on: https://gerrit.openafs.org/13686 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Mark Vitale [Thu, 23 May 2019 03:03:11 +0000 (23:03 -0400)]
auth: eliminate pointless retries in ktc_ListTokensEx
ktc_ListTokensEx is an iterator to provide the names of each cell for
which a user has a token set. It does this by looking for the 1 through
nth token set for a given user. However, as currently implemented,
it always continues searching up to the 100x safety limit even when
there are no more token sets for the user.
Instead, return immediately when VIOC_GETTOK2 returns EDOM (no more
tokens for this user).
Mark Vitale [Thu, 25 Oct 2018 14:27:41 +0000 (10:27 -0400)]
viced: correct option parsing for -vlru*, -novbc
Commit a5effd9f1011aa319fdf432c67aec604053b8656 "viced: Use libcmd for
command line options" modernized the option parsing for (da)fileserver,
but introduced a few errors for the following options:
Cheyenne Wills [Tue, 25 Jun 2019 16:40:53 +0000 (10:40 -0600)]
util: serverLog using memory after free
clang's scan-build detected a "use of memory after it is freed"
condition.
The function OpenLogFile frees the variable ourName before creating a
duplicate of the name passed to it. However there is a call that uses
ourName as the parameter: OpenLogFile(ourName). This results in freeing
ourName then doing a strdup of the same memory location.
Test the passed parameter and if it's the same as ourName already skip
the free and strdup.
khm [Tue, 25 Jun 2019 19:51:21 +0000 (12:51 -0700)]
add dkms dependency in Red Hat unit file
Currently, there is no explicit relationship between OpenAFS and dkms.
If dkms needs to rebuild the kernel module, OpenAFS will fail to mount
because modprobe will not load the module. This change specifies that
OpenAFS should run after dkms if dkms is present.
Reviewed-on: https://gerrit.openafs.org/13654 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Laß <lass@mail.uni-paderborn.de> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit fbe2a03aa69bc19768302685d902a25e4d6e157a)
Mark Vitale [Thu, 23 May 2019 02:52:10 +0000 (22:52 -0400)]
pioctl: limit fruitless token searches
getNthCell searches the afs_users table for the nth token set belonging to a
given user. However, it is impossible for a user to have more than one
token set per cell. If the caller specifies a number greater than the
total number of cells this cache manager knows about, we know the search
will be fruitless.
Instead, return early in this case, avoiding both the lock and the
search.
Reviewed-on: https://gerrit.openafs.org/13597 Tested-by: BuildBot <buildbot@rampaginggeek.com> Tested-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit fc7e1700fe84f623fb9163466d24226df00b1a2c)
Change-Id: Idfda263af173a7ca081fcea3eef0ec4a63e66eda
Reviewed-on: https://gerrit.openafs.org/13639 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Pat Riehecky [Fri, 1 Jun 2018 21:33:37 +0000 (16:33 -0500)]
Fix static expressions in conditionals
The conditions in these if statements are always true (or always false).
Remove the check in cmdebug.c, as it is unnecessary, and fix the check
in vlclient.c to actually check for a valid voltype. (via cppcheck)
Reviewed-on: https://gerrit.openafs.org/13158 Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 5cd5cd9fa8754a5af346fa6a392363b046316c75)
Change-Id: Ie3a2d6bfc99d1b5adf0524afc29dac30b655d04d
Reviewed-on: https://gerrit.openafs.org/13638 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Fri, 17 May 2019 01:01:17 +0000 (20:01 -0500)]
Use the ppc64le_linuxXX sysname for ppc64le builds
Commit 191e18eb (Open ppc64le_linux sysname space) added the
ppc64le_linux26 sysname, but it still must be manually specified when
running on ppc64le. Use the ppc64le_linux26 by default on ppc64le, so
we can compile without needing to specify an explicit sysname.
Reviewed-on: https://gerrit.openafs.org/13593 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 4b6a4ff31a4197504bbcf2d4c14c24dee672d40e)
Change-Id: Icf8f8b42c499dc42bf5d637dae5ad3e261e68512
Reviewed-on: https://gerrit.openafs.org/13637 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
In afs_linux_readdir, if we detect an error code from BlobScan,
currently we 'break' out of the current while() loop. But right after
this loop, we reset 'code' to 0, ignoring the error we just got from
BlobScan, and acting like we just reached the end of the directory.
This means that if BlobScan could not process the given directory at
all, we'll just fail to iterate through some of the entries in the
given directory, and not report an error.
To fix this, process errors from BlobScan like we do for
afs_dir_GetVerifiedBlob, and return an error code and log a message
about the corrupted dir.
Reviewed-on: https://gerrit.openafs.org/13430 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 63f015d05293cd853dbd44e5115e6b378644dfb6)
Change-Id: Ia25bcfdb70cdb1dd1a7ce0efb84ef76beb78b247
Reviewed-on: https://gerrit.openafs.org/13591 Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Thu, 17 Jan 2019 05:46:34 +0000 (23:46 -0600)]
afs: Throw EIO in DRead on empty dir blob
DRead currently returns ENOENT if we try to read a page beyond the end
of the given dir blob. We do this to indicate we've hit EOF, but we do
this even if the dir blob is completely empty (which is not a valid
dir blob).
If a dir blob in the cache is truncated due to cache corruption
issues, that means we'll indicate a normal EOF condition in that
directory for most code paths. If someone is trying to list the
directory's entries, for instance, we'll just return that there are no
entries in the dir, even though the dir itself is just invalid.
To avoid this for at least some cases, return an EIO error instead if
the dir blob is completely empty.
Reviewed-on: https://gerrit.openafs.org/13429 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 86d04ea70fd2e99606b1d1b5b68d980d92e7a3cd)
Change-Id: I067aae1f949051169225a3cc0bdba35ad76a4ec2
Reviewed-on: https://gerrit.openafs.org/13590 Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Thu, 16 May 2019 21:12:47 +0000 (16:12 -0500)]
Do not define AFS_SYSCALL for ppc64le_linux26
AFS_SYSCALL is defined to the syscall number we can use for a certain
platform (for pioctls and other AFS-specific kernel calls). On many
modern platforms, such as Linux, we don't use direct syscalls anymore,
instead routing our AFS-specific syscalls through an ioctl, and
AFS_SYSCALL is just used as a fallback for compatibility for older
OpenAFS releases that might still be using the syscall.
For new platforms, we have no need for this compatibility code path,
since there is no existing code we might need to be compatible with.
We should avoid defining AFS_SYSCALL for those, so we can avoid
manually-issuing syscalls in more cases. The ppc64le_linux26 platform
is a very new platform (introduced in 191e18eb "Open ppc64le_linux
sysname space"), and so should not have AFS_SYSCALL defined.
So, remove AFS_SYSCALL from ppc64le_linux26's param.h.
Reviewed-on: https://gerrit.openafs.org/13592 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Tested-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 46563f929a851032d785634763963808d6e2bfeb)
Change-Id: Ib161b50a9156d3790134de4e1a8e66a1356e0fb6
Reviewed-on: https://gerrit.openafs.org/13636 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
redhat: RHEL8 add elfutils-devel as build dependency for kernel module
Building the kernel modules under RHEL8 produces the following error
message:
Makefile:952: *** "Cannot generate ORC metadata for
CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or
elfutils-libelf-devel". Stop.
Add elfutils-devel to the BuildRequires in the rpm spec when building
rhel >= 8
Add elfutils-devel to the BuildRequires in the rpm spec that
openafs-kmodtool produces
FIXES 134900
Reviewed-on: https://gerrit.openafs.org/13560 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 13817774518ada28f5fe68e0d00ef5dd00b67b55)
Change-Id: If4f453e6c459a2865626d4fd71bb47030e3deb58
Reviewed-on: https://gerrit.openafs.org/13563 Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Fri, 28 Sep 2018 19:55:56 +0000 (14:55 -0500)]
afs: Raise osidnlc NCSIZE
The currrent size of the osi DNLC is very small; only 300 entries.
Raise it to 4096 entries, to give it some chance of actually helping.
In the future, of course, this should be runtime configurable, and we
should also raise the hash table size. For now, just raise the number
of entries without changing anything else, to try to make sure nothing
breaks.
With the hash size of 256, this means our hash chains will be at least
16 items long. However, traversing even hundreds of hash items should
still be better than frequently hitting the disk cache to find
entries, and acquiring more locks, etc.
Reviewed-on: https://gerrit.openafs.org/13531 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 12b46b6af778625a9c360dca61a59fcf30b76fd1)
Change-Id: Ib4fd8bd01e2df22617e5a549d4ac76ba1d50b2fd
Reviewed-on: https://gerrit.openafs.org/13559 Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> 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>
Andrew Deason [Thu, 17 Jan 2019 06:04:36 +0000 (00:04 -0600)]
dir: Honor non-ENOENT lookup errors
Currently, several places in src/dir/dir.c assume that any error from
a lower-level function (e.g. FindItem) means that the item we're
looking for does not exist in that directory. But if we encountered
some other error, that may not be the case; the directory blob may be
corrupt, we may have encountered some I/O error, etc.
To detect cases like this, return the actual error code from FindItem
&c, instead of always reporting ENOENT. For the code paths that are
actually specifically looking for if the target exists (in
afs_dir_Create), change our checks to specifically check for ENOENT,
and return any other error.
Do the same thing for a few similar callers in viced/afsfileprocs.c,
as well.
FIXES 134904
Reviewed-on: https://gerrit.openafs.org/13431 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 0b3bd1b7cdc88ba62c8cd540e8628faa84e33cf9)
Change-Id: Ia81ff85821c1987b97390a683f1d442ca70db41e
Reviewed-on: https://gerrit.openafs.org/13543 Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Andrew Deason [Thu, 21 Mar 2019 20:24:06 +0000 (15:24 -0500)]
LINUX: Avoid lookup ENOENT on fatal signals
Various Linux kernel operations on various Linux kernel versions can
fail if the current process has a pending fatal signal (i.e. SIGKILL),
including reads and writes to our local disk cache. Depending on what
and when something fails because of this, some parts of libafs throw
an ENOENT error, which may propagate up to callers, and be returned
from afs_lookup(). Notably this can happen via some functions in
src/dir/dir.c, and previously was possible with some code paths before
they were fixed by commit 2aa4cb04 (afs: Stop abusing ENOENT).
For the most part, the exact error given to the userspace caller
doesn't matter, since the process will die as soon as we return to
userspace. However, for ENOENT errors specifically for lookups, we
interpret this to mean that the target filename is known to not exist,
and so we create a negative dentry for that name, which is cached.
Future lookups for that filename will then result in ENOENT before any
AFS functions are called.
The lingering abuses of the ENOENT error code should be removed from
libafs entirely, but as an extra layer of safety, we can just avoid
returning ENOENT from lookups if the current process has a pending
fatal signal. So to do that, change all afs_lookup() callers in
src/afs/LINUX to translate ENOENT to EINTR if we have a pending fatal
signal. If fatal_signal_pending() is not available, then we don't do
this translation.
FIXES 134904
Reviewed-on: https://gerrit.openafs.org/13530 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 8b6ae2893b517bd4e008cae94acff70abe4d2227)
Change-Id: I8bf1b24c97ed74b0b457d79f48b2f40416c1d37e
Reviewed-on: https://gerrit.openafs.org/13542 Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
projects / packages / o / openafs.git / log