[OpenAFS] little oddity in 1.4.2
Marcus Watts
mdw@umich.edu
Sun, 29 Oct 2006 23:38:14 -0500
Juha =?UTF-8?B?SsOkeWtrw6Q=?= <juolja@utu.fi> sent:
...
> > Well, that's definitely broken. Use of -localauth shouldn't have
> > affected this; it should figure out what the cell is
> > from /etc/openafs/ThisCell and then look up the servers
> > from /etc/openafs/CellServDB and it sounds like it's not doing that
> > properly.
>
> Is the brokenness in vanilla or just Debian version? I.e. which way
> should I file the bug?
>
> Just one more bit of info, in case it's relevant: the
> contents /etc/openafs are upservered from a Debian/stable running openafs
> 1.3.81. Thus if there is indeed some change in how the files are parsed
> (as suggested by Scott Peshak), I will have to take down upclient on this
> 1.4.2-host. It would be inconvenient, but not catastrophical since we'll
> be upgrading to etch anyway sooner or later.
...
Oh... I bet I know what the problem is.
I bet you have a blank or tab after your cell name in ThisCell.
It's possible you also have white space before, but you would
probably have noticed this.
Older versions of openafs used `rc = fscanf(tf, "%s", tbuffer);'
to read in the cell name. Current versions use fgets + strchr
to trim off the expected trailing newline. This is in 'src/auth/cellconfig.c'
It's not a completely unreasonable fix -- the older version
had a comment which frankly admitted there was an overflow issue.
The easiest fix is probably to remove the trailing whitespace.
A more "clever" fix would be to replace the format statement
with "%255s". This would continue to trim leading & trailing spaces,
is slightly more compact, and also avoids the overflow. It
does pull in scanf from libc -- if you were using static binaries and
cared about memory space you would not want to do that (because this
would also pull in floating point input conversion).
-Marcus