[OpenAFS] token oddities under Linux

[Tino Schwarze]

On Fri, Jul 26, 2002 at 03:36:07PM +0200, Marc Schmitt wrote:

> >>Judging by your first question, you don`t believe what I get, do you? In
> >>other words, you`ve never seen that effect on your Linux boxes???
> > 
> > I can verify this behavior on my Linux and Solaris machines:
> > 
> > HOWEVER -- I'm running the same versions of OpenAFS on the same platforms.
> > We're both running 1.2.3 under Solaris and 1.2.5 under Linux.  Could it be
> > a 1.2.5 problem, rather than a Linux problem?  Does anyone have 1.2.5
> > installed on a Sparc, or 1.2.3 installed under Linux?
> 
> On some older installation (RedHat 7.1):
> 
> bash-2.04$ id
> uid=1049(schmitt) gid=99(nobody) 
> groups=99(nobody),2000(ssw),14(uucp),10(wheel)
> bash-2.04$ uname -a
> Linux lin 2.4.9-6smp #1 SMP Thu Oct 18 09:22:57 EDT 2001 i686 unknown
> bash-2.04$ rpm -q openafs
> openafs-1.2.2-rh7.1.1
> bash-2.04$ id
> uid=1049(schmitt) gid=99(nobody) 
> groups=99(nobody),2000(ssw),14(uucp),10(wheel)
> bash-2.04$ klog -setpag mschmitt
> Password:
> bash-2.04$ id
> uid=1049(schmitt) gid=99(nobody) 
> groups=34389,35722,99(nobody),2000(ssw),14(uucp),10(wheel)
> 
> 
> You`re right, it seems to be a problem of version 1.2.5, it obviously 
> worked with 1.2.2.

It also works with 1.2.3. On a SuSE 7.3 (Linux powertower 2.4.17 #1 Tue
Apr 23 14:53:19 CEST 2002 i686 unknown)

It does not seem to work with 1.2.5 though - I don't have a 1.2.4 handy,
can anybody please test this? I think this should be worth a security
advisory - people expect "klog -setpag" to work and to secure them. It
renders a machine running 1.2.5 (and maybe 1.2.4) less secure than the
administrator might assume.

BTW: I've just taken a look into src/kauth/token.c and notice that there
_might_ be a setpag related omission: In line 221 (which is inside a
branch related to "inter-cell mechanism") there is a call to
ktc_SetToken which - unlike the call later - does not take dosetpag into
account. But this should not be related to the issue we're seeing, I'm
reporting it just-in-case.

[...half an hour later...]
Okay, I've spotted the error. It's been introduced with 
STABLE12-pioctl-avoid-inadvertantly-setting-new-pags-due-to-gcc-20020516
which only changes line 1418 of afs_pioctl.c from
    if (flag & 0x8000) {
to
    if (flag & 0x8000 != 0) {
. Paraphrasing Stroustroup chapter 6.2.3 (I've got the german version...):

    There are cases where the priority of operators does not deliver the
    "apparent" result. Example:

        if (i&mask == 0)

    This does not apply a mask to i and checks whether the result is
    zero. Since == has a higher priority than &, the expression is
    evaluated as i&(mask==0). [...]

Therefore, the above line should be changed to
    if ((flag & 0x8000) != 0) {

The above mentioned diff has been applied after 1.2.4 was released -
1.2.4 should therefore be considered safe with regard to this issue.

HTH! Tino.

-- 
             * LINUX - Where do you want to be tomorrow? *
                  http://www.tu-chemnitz.de/linux/tag/