When installing on 64-bit Windows we need to install the 32-bit and 64-bit
shell extensions under different HKCR keys. Otherwise, only one of the
explorer versions will get an extension handler.
This change is not as important for OpenAFS as it was for KFW as
OpenAFS does not issue betas with the same build numbers as final
releases. However, for users of daily builds when build numbers
are not being incremented it will provide benefit.
We modify the upgrade rules to include the current version number
and then block the uninstall if the currently installed package
is the one that is being installed.
The change applies to both the regular installer and the 32-bit
tools for WOW64 environments.
FIXES 60161
A dropbox is a directory with ACLs 'li' that permits a user to create
a new file but not be able to read other files within the same directory.
The 1.5 Windows clients have not been able to write to dropboxes since
the addition of the locking code. The lock acquisition test assumed
that if the user did not have PRSFS_LOCK or PRSFS_WRITE that it would
be unable to obtain a lock. It did not take into account the special
treatment of PRSFS_INSERT by the file server and so never bothered to
ask.
As it turns out though, the locking situation is more complex than one
might think. If the server is 1.4.1 or earlier, it will not grant
any locks for users with INSERT. The PRSFS_LOCK privilege is required.
For 1.4.2 through 1.4.4, write locks will be granted if the user has
PRSFS_INSERT but a read lock will not be granted unless the user has
PRSFS_LOCK. Therefore, if the server advertises the WRITELOCKACL
capability bit if the read lock is not granted a write lock can be
attempted.
For 1.4.5 and 1.5.20 and above, the file server will grant read locks
if the user has PRSFS_WRITE or PRSFS_INSERT. (Insert only applies if
the user is the creator of the file).
This patch handles all of the above possibilities. In the pre-1.4.2
case a read-lock request will be faked locally.
FIXES 60137
commit updates to the docs for obsolete stuff
====================
This delta was composed from multiple commits as part of the CVS->Git migration.
The checkin message with each commit was inconsistent.
The following are the additional commit messages.
====================
also the appendix file
the permission to obtain a write-lock is granted either by having the
"w" permission or the "i" when owning the file. The permission to obtain
a read-lock has been granted by having the "k" permission. However it
makes no sense that someone can obtain a write-lock but not a read-lock.
This patch grants permission to obtain read-locks to those who can obtain
write-locks.
Background: OpenAFS is vulnerable to crashing in the linux kernel symlink
code when running on kernel versions between 2.6.10 to 2.6.12. This also
includes all RHEL4 kernels, because RHEL4 includes the code from 2.6.10. The
problem is that the symlink text caching API, page_follow_link() et al, is
unsuitable for network filesystems where the page cache may be invalidated
in parallel with a path lookup.
This crash can be triggered easily by doing a bunch of path lookups
involving symlinks (e.g., stat() on various files pointed to through links),
while simultaneously running 'fs flushvol' on the volume containing the
symlinks.
The simplest way to fix this problem is to disable the use of symlink text
caching when the kernel does not provide a usable symlink API.
Based on Chris Wing's analysis which stated in part:
GFP_NOFS tells the allocator not to recurse back into the filesystem if it's
necessary to free up memory. However, vmalloc() does not have such an
option. Therefore, calling osi_Alloc() to request more than a page of
memory may end up recursing back into AFS to try to free unused inodes or
dentries.
In this case, what happened was that osi_Alloc() is called within an
AFS_GLOCK(); osi_Alloc() calls vmalloc() which tries to free dentry objects,
which then calls back into the AFS module. Unfortunately, AFS_GLOCK() is
already held and we deadlock.
The afskfw library contains an unprotected call to krb5_free_context
which can result in krb5_free_context being called with a NULL pointer.
MIT's Kerberos libraries do not check that the pointer is non-NULL and
will attempt to use it as a valid pointer which will in turn result
in an invalid memory access error.
This library is used by afslogon.dll which is loaded by winlogon.exe.
If the krb5 profile is invalid, the krb5_init_context call will fail
to allocate a krb5_context structure which can then result in
krb5_free_context being called with a NULL pointer.
An unhandled exception within winlogon.exe will cause a blue screen event
on Windows 2000, XP and 2003.
add a new Windows only pioctl VIOC_PATH_AVAILABILITY that is used
to query the server status for a specified path. Return values
include:
online
offline
all busy
all down
not afs
Fix eventlog reporting. Do not attempt to log an event if the event
source registration fails. Use DebugEvent0 instead of DebugEvent
when there are no parameters.
Modify the LOOKUPKEYCHAIN macro to recognize ERROR_MORE_DATA errors.
Fix the reading of Domain specific configuration for LogonScript and
TheseCells. Previously the dwSize value was being overwritten so that
subsequent RegQueryValueEx call would fail.
Fix a memory leak in the TheseCells reading code.
Add support for Domain specific "Realm" specification. The realm is
the realm to be appended to the username. When logging in as a domain
or to the local machine, the specified "Domain" name is not going to be
a valid realm name.
Construct a proper principal name based upon the domain specified realm
for use in obtaining tokens with KFW.
If the domain specified "TheseCells" list includes the default cell,
do not obtain tokens twice.
There are two serious problems with integrated logon:
(1) openafs afslogon.dll obtains Kerberos v5 tickets and then forwards them
into the logon session. This was done because MIT KFW did not have
such functionality. As of KFW 3.1, KFW does, so we are removing it.
the functionality worked by copying the credentials to a FILE ccache
and then using the Logon Event Handler to move the credentials into
an API ccache and delete the temporary file. For non-interactive
logons the Logon Event handlers do not get triggered. Neither do
LogonScripts get executed. As a side effect, for each logon a
credential cache file was left behind.
(2) when combined with non-interactive logons, there are some very bad
side effects if a network provider performs Kerberos v5 operations.
Each logon occurs in a new logon session and will spawn a private
copy of krbcc32s.exe.
As a result, integrated logon is being disabled for non-interactive
logons.
