[PATCH] 2.2 kernel bug in utimes() and its results (m4 FTBFS, coreutils breakage, etc.)

[viro]

First of all, apologies for posting here.  Use of BTS would lead to
too many bug reassignments in that case ;-/

Summary: there is a bug in 2.2 kernels that leads to breakage of
glibc 2.3.2 on 2.2 boxen, to breakage of coreutils and to FTBFS of m4 on
alpha.  Additionally, there's a nasty issue with alpha buildd.  That is to
say, 5 sides involved and a plenty of space for finger-pointing ;-/

1) Source of the bug: in 2.2 (and 2.4 prior to 2.4.19-rc2) sys_utimes()
lacks a test on times==NULL branch.  It should have the same behaviour as
sys_utime() - if we ask to set timestamps to present (second argument of
syscall is NULL), caller must either have write permissions to file or
be its owner.  In 2.2 the second part is missing.

That is to say, if /tmp/foo is your file and its r--r--r--, you
can't do utimes("/tmp/foo", NULL).  It will fail with -EACCES on 2.2.
Note that you *CAN* do utimes("/tmp/foo", &tvp) - IOW, you can set the
timestamps to whatever values you want, which is more than the failing
call would do.

It is a bug, it makes no sense, it violates POSIX, it's contrary
to other kernels' behaviour _and_ it had been fixed in 2.4 for about a year.
Fix is a one-liner and would apply to any 2.2.x:
--- linux/fs/open.c Sun Jul  1 13:32:19 2001
+++ linux.fix/fs/open.c Fri Sep 26 02:32:22 2003
@@ -262,7 +262,8 @@
newattrs.ia_mtime = times[1].tv_sec;
newattrs.ia_valid |= ATTR_ATIME_SET | ATTR_MTIME_SET;
} else {
-   if ((error = permission(inode,MAY_WRITE)) != 0)
+   if (current->fsuid != inode->i_uid &&
+   (error = permission(inode,MAY_WRITE)) != 0)
goto dput_and_out;
}
error = notify_change(dentry, &newattrs);
That's precisely what had been done in 2.4 and that's what we should do in
2.2.

That was kernel side of things.  Now, for visible userland bugs:


2) m4 FTBFS on alpha.

It fails when built on 2.2 kernel with glibc 2.3.2.  What happens is
touch ./stamp-checks
touch: cannot touch `./stamp-checks': Permission denied
which breaks the build.

Note that stamp-checks exists and has 444 as mode.  touch(1) should *not*
break on that.  It doesn't break on x86.  It doesn't break with 2.4 kernel.
It doesn't break with old glibc.  With the combination above (2.2 on alpha +
glibc 2.3.2, which is what lully ran at the time of 1.4-17 build attempt)
it *does* break.

At that point m4 is exhonerated - FTBFS is a consequence of touch(1) breakage,
so it's a side-effect of coreutils being broken.


3) coreutils and touch(1).

On alpha running 2.2 kernel with glibc 2.3.2, try the following:
% touch foo
% chmod 444 foo
% touch foo
It will give you "Permission denied" on the second touch(1).

What happens is that touch(1) correctly calls utime("foo", NULL).  Which
breaks on aforementioned combination.  Note that it's libc utime(), not
the kernel one.   Which exhonerates coreutils - we are in libc land.


4) libc and utime()/utimes().

Both utime() and utimes() end up using the same syscall.  The choice depends
on platform; generally sys_utimes() is prefered.  2.2 (and 2.4) x86 do not
have sys_utimes in syscall table (2.6 does, but it doesn't have the bug in
question).  On alpha and sparc sys_utimes() is a syscall, so both utime() and
utimes() end up calling it.

Note that both old and new libc have the bug on 2.2/alpha.
utimes(pathname, NULL) will fail if you do it to your read-only file.
The difference between their behaviour is in utime(name, NULL).  Old
libc has basically
struct timeval timevals[2];
if (times) {
fill timevals from *times;
} else {
call gettimeofday() set timevals[0] and timevals[1] to current;
}
utimes(name, timevals);

New one doesn't bother with gettimeofday() and (correctly) calls utimes(name,
NULL) directly.

Old behaviour had masked the kernel bug in question, since we didn't pass NULL
to sys_utimes().   *However*, that had lead not only to extra syscall, but
to very real breakage.  Namely, if file was writable to you, but you were
not the owner,  you would get "permission denied" from uname(name, NULL).
Which is a bug - non-owners are not allowed to *set* timestamps, but they
can reset them to present on files they can write to.  New behaviour fixes
that problem and is clearly the Right Thing(tm).

Unfortunately, it exposes the sys_utimes() breakage not only in utimes(3)
(where it was exposed for years) but in utime(3), where it triggers the
userland breakage we were not used to (see #2 and #3 for some examples).


Now, it's obvious that
a) there is a bug.
b) there are only two places where it might've been fixed - 2.2 kernel
and glibc.
c) "fix" in glibc would reintroduce old bugs and would be useless on
newer kernels.

Seeing that kernel-side fix (== what had been done in 2.4/2.5) is trivial
and obviously cor

Re: Debian should not modify the kernels!

[viro]

On Sun, Sep 28, 2003 at 01:10:27PM +1000, Herbert Xu wrote:
> I do not believe that this patch has caused excessive grief for the
> benefits that it brings.  In fact, conflicts between the Debian kernel
> source and random kernel patches floating around are a fact of life.
> 
> For example, the grsecurity patch has had a history of conflicts with
> various patches in the Debian kernel source.  Most of those patches that
> caused conflicts were in fact essential security fixes.  You can review
> this for yourself by visiting to the BTS entry for the grsecurity
> package.

That has more to do with the fact that grsecurity is an intrusive pile of
garbage, splashed pretty much all over the tree (which, incidentally, is
a large part of reasons why it is unfit for upstream kernel).

For crying out loud, it's a half-megabyte monolitic patch.  Even devfs
was slightly smaller when it had finally dripped into the tree.  If
somebody wants to play with it - they'll have to either
a) split the damn thing into series of localized chunks and enjoy
relatively easy resolution of conflicts with other patches or
b) wear "I'm a sadomasochist and proud of it" T-shirt and leave
everybody else alone.

Look, it's that simple - authors of patch had chosen to be antisocial and
kept it a monolit; that makes it a second-class citizen as far as merges
are concerned.  Less intrusive patches get precedence.  End of story.

Re: A case study of a new user turned off debian

[viro]

On Mon, Nov 03, 2003 at 02:22:00PM -0800, Erik Steffl wrote:
>   Oh, not this crap again. Or perhaps you're contending that what is 
> usefull for you is usefull for everybody.
> 
>   Hint: there's more to "useful" than old version of software in early 
> stages of development. Lot of desktop oriented apps are changing fast 
> and older version are fairly poor (functionality, stability etc.) - open 
> office, mozilla (and other browsers), kde, gnome etc. Lot of new HW has 
> a better chance to be (better) supported on newer system (are new 
> kernels available for stable?)

man make-kpkg

Debian is *wonderful* for kernel development, but I wouldn't touch Herbert's
kernels with a ten-feet pole.  And yes, new kernels work fine on -stable:
$ grep '^deb ' /etc/apt/sources.list 
deb http://http.us.debian.org/debian woody main contrib non-free
deb http://http.us.debian.org/debian woody-proposed-updates main contrib 
non-free
deb http://non-us.debian.org/debian-non-US woody/non-US main contrib non-free
deb http://non-us.debian.org/debian-non-US woody-proposed-updates/non-US main 
contrib non-free
deb http://security.debian.org woody/updates main contrib non-free
$ uname -a
Linux miles 2.4.23-pre8 #1 Fri Oct 24 02:08:34 EDT 2003 alpha unknown
$

- no need to put -testing on the firewall box.  The rest of Linux boxen
run -testing here...

Re: A case study of a new user turned off debian

[viro]

On Tue, Nov 04, 2003 at 01:48:25PM +1100, Martin Michlmayr wrote:
> * [EMAIL PROTECTED] [2003-11-03 22:52]:
> > but I wouldn't touch Herbert's kernels with a ten-feet pole.
> 
> Can you elaborate why?


a) I can do better
b) I don't do huge monolitic patches
c) I don't like Herbert's taste
d) some boxen are used for 2.6 work

as long as make-kpkg produces valid .deb...

Re: Grsec/PaX and Exec-shield

[viro]

On Tue, Nov 04, 2003 at 07:51:52PM +0100, Josselin Mouette wrote:
> Le mar 04/11/2003 à 16:56, [EMAIL PROTECTED] a écrit :
> > Also, I think both you and Ingo will be interested to see the results of 
> > a bugfixed version of paxtest.  Are you so certain that Exec-shield 
> > stops execution in shared library bss/data?  Or did you just say it 
> > because that's what a program told you?  Do you want to change your 
> > answer before it's released?  Or can you tell me why Exec-shield will 
> > prevent execution in those areas?  If you can tell my why, I'll be sure 
> > to tell you why it doesn't, and why it's impossible for it to.
> 
> Give us facts. Are you advertising the latest Windows 2012 server
> software before it is written, or discussing about computer security?

Nah, he just tries to imitate Theo.  Unfortunately, he misses some elements -
clue, taste and understanding of the difference between arguments and
handwaving.  Working in that area can make one an asshole; however, being
an asshole does not qualify for such work...

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

[viro]

On Fri, Nov 07, 2003 at 04:22:27PM -0500, Daniel Jacobowitz wrote:
 
> Then how do you suggest maintaining a kernel 2.4.20 for one
> architecture and a 2.4.22 for another architecture, when you can't even
> test on either of them?  And how do you expect to ever upgrade the
> result without duplicating all the work done by all the existing kernel
> package maintainers for all Debian architectures?
> 
> This doesn't even make any sense.  Might as well just set Architecture:
> i386.

Situation when 2.4.22 does not work on architecture in question is a *bug*,
plain and simple.  Same as when 2.3.2 doesn't work on the same architecture.
And correct way to deal with that is to report these bugs upstream and/or
submit patches fixing them.

BTW, is there any reason why kernel-patch-2.4.22-powerpc-2.4.22 exists?

I'm looking through the splitup of that patch right now (and by $DEITY,
it should've been split from the very beginning - what with it being
pulled from ppc BK tree).  There we have:
1) sungem patch
2) minor cleanup in ne2k-pci (platform-independent)
3) extra PCI ID in tg3 table.
4) change in drivers/sound/config.in (affects only powerpc builds)
5) usb-ohci - more conservative alignment.
6) aty128fb.c ifdef changes (affects only powerpc builds)
7) additional constants defined in radeon.h (none of them used in
   #ifdef/#ifndef/defined())
8) drivers/video/Config.in change (affects only powerpc builds)
9) patches in arch/ppc and include/asm-ppc (affects only powerpc builds)
10) extra PCI IDs in pci_ids.h

Out of these, ##2--4,6--10 can and should be in the common tree.

#5 either should be arch-conditional (it's a couple of lines) or
it should be simply applied on all platforms - depends on the reasons
why it exists.

#1 needs testing on sparc.  Until it gets such, make it arch-conditional.

And there goes the bleeding package.  I mean, WTF?  We don't have separate
source packages for gcc-3.3/powerpc or gcc-3.3/alpha.  We certainly *do* have
patches unique to these platforms in there.  And gcc, glibc and binutils are
autobuilt.  I sincerely hope that it doesn't imply "Architecture: i386" on
those.

Sigh...

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

[viro]

On Fri, Nov 07, 2003 at 10:59:51PM +0100, Frank Gevaerts wrote:
> On Fri, Nov 07, 2003 at 10:48:06PM +0100, Robert Millan wrote:
> > > Then how do you suggest maintaining a kernel 2.4.20 for one
> > > architecture and a 2.4.22 for another architecture, when you can't even
> > > test on either of them?  
> > 
> > I wouldn't. I'm going to track the latest minor version, just like the rest
> > of Debian packages do.
> 
> So you would recommend dropping support for architectures that do not
> boot with the latest kernel ?

Submit the fscking bug reports and patches.  Same as with toolchain
packages.

Re: create new Debian-Kernel project (was: ITP: linux -- Linux 2.4 kernel)

[viro]

On Mon, Nov 10, 2003 at 05:11:45PM +0100, Eduard Bloch wrote:
>   initrd-on-cramfs fix ,

You mean the kludge that craps in fs/block_dev.c?  If so, feel free to
can it - the proper fix is to switch cramfs_read() to use of pagecache
and it's going upstream.

Re: libc6 bug? or C programming error?

[viro]

>   /* map the file and load an extra page in case the new line expands the
>  file across the page boundary; adding 2 allows for the truncating
>  effect of integer division.  Forcing an extra page ensures
>  that we can identify the end of the buffer by finding a NUL */

No, it does not.  Access past the EOF will give you page fault, not zero-filled
page.

>   if ((int)(buf = (char *) mmap(buf, ((c / getpagesize()) + 2) * 
> getpagesize(),
>   PROT_NONE, MAP_SHARED, fileno(ucf), 0)) == -1) {
> perror("Could not map user_clusters");
> exit(LOC_ERR_READ_FAIL);
>   }

Re: Changes in formal naming for NetBSD porting effort(s)

[viro]

On Thu, Dec 18, 2003 at 05:03:55AM +, Henning Makholm wrote:
> Scripsit Kevin Kreamer <[EMAIL PROTECTED]>
> 
> > In the case of a NetBSD libc, you could use
> 
> > Debian NBSD/NBSD
> 
> > basically having the first half signify which libc is used.
> 
> Wouldn't that be a major retcon? AFAIU the "GNU/" in Debian GNU/Linux
> says that we're using GNU userland tools such as cp, mv, diff, cc,
> make, nroff, etc. That's prominently visible to users; the libc is a
> technical detail that most users wouldn't care about unless it breaks.

Hardly.  Guess which *roff, gcc, diff, tar, etc. is there in *BSD?  And
considering the state of coreutils...  not much to boast there.

About the only thing that gives any real weight to "GNU/" stuff is glibc -
the rest is either common on all free Unices (and GNU doesn't see that
as grounds for claim on renaming *BSD to GNU/*BSD) or... well, less than
impressive, to put it mildly.

IOW, about the only way GNU/Linux as a port name makes sense is "what libc
do we have here"/"what kernel does it run on".

Re: GNU within the name (Was: Changes in formal naming for NetBSD porting effort(s))

[viro]

On Thu, Dec 18, 2003 at 10:41:46AM +0100, Mathieu Roy wrote:
> You are currently saying that the GNU in GNU/Linux is justified by the
> glibc and not by any other GNU software, because these GNU software
> are common on other unixes.
> 
> Why? If you are right that others unixes uses widely GNU software,
> maybe they should consider recognize the GNU part of the their
> system. But that's a different story.
> 
> If we follow your theory, it means that if someday another system use
> the glibc, we should remove the GNU from the GNU/Linux name. 

Why not?

> It does not make sense: the GNU part of the name shows that the system
> used is the system designed/initiated by the GNU project running with
> the kernel Linux, which is not part of GNU. It does not mean that
> there are GNU software rarely used elsewhere in the system! 

Debian had not been initiated by GNU project, IIRC.  "Designated" is
closer to reality, but that wouldn't warrant _anything_ - after all,
gcc had been designated as a primary C compiler on a lot of systems,
but that doesn't make it {lots of organizations}/gcc.  It doesn't work
in that direction - *contributor* may have a right to make demands, not
the other way round.

And yes, GNU *had* contributed stuff.  The main dependency being glibc.

BTW, if you are talking about frequency of use, glibc beats everything
else by far.  With X11 and assorted daemons (almost all of them coming
not from GNU) contending for the second place - depends on the type of use.

If we ever get a replacement libc that would really work as replacement...
on such system GNU claims would become much weaker.  Not that there was
a serious chance of that happening - drop-in replacement of glibc on Linux
would be a lot of work and so far none of the alternative libc projects had
tried to pull that off.

Re: GNU within the name

[viro]

On Thu, Dec 18, 2003 at 12:15:37PM +0100, Mathieu Roy wrote:
> > Why not?
> 
> You said what I expected from you: you revealed that you disbelieve
> that the system should be called GNU/Linux. Good to know in this kind
> of discussion.



I'm not a True Believer, if that's what you mean.

> Why not? 
> 
> I will not reply to that question, I think there is enough information
> on the web about that, for instance
>  
 
You do realize that you are emulating a garden-variety bible-thumper here?

> When I'm told that a system is running GNU/whatever, I expect first to
> find there GNU coreutils, GNU bash, GNU Emacs, GNU Compiler
> Collection, gzip, GNU awk,GNU make, the GNU Debugger, GNU sysutils,
> GNU tar, GNUpg, GNU grep, GNU mailutils, GNU ncurses, GNU readline,
> GNU shellutils, GNU wget... 
> 
> These are required components of a system. The daemons you install on

Oh, really?

emacs:  priority: optional
gawk:   priority: optional (BTW, mawk is required)
make:   priority: standard
gcc et.al.  ditto (at most)
gdb:ditto
sysutils:   optional
gnupg:  standard
mailutils:  optional
readline:   standard
shellutils: eaten by coreutils, what the hell are you talking about?
wget:   optional

> that system are not basis components, as you may well not be using
> them at all.

Like, say it, init?  Or cron/anacron/combination thereof?  Or syslogd, or...?

> Anyway, your proposal is unrelated to the current subject: the NetBSD
> port of Debian GNU. Unless you are about to propose that Debian
> completely change it's naming policy, I think we can stop this
> dicussion now.

As I've said, until the hell freezes and we get a drop-in replacement of
glibc, it's moot - Linux-based ports will be glibc-based anyway.  I'm not
particulary interested in discussing the appropriate names for inexistent
objects, so I'm only glad to drop that.

Re: GNU within the name (Was: Changes in formal naming for NetBSD porting effort(s))

[viro]

On Thu, Dec 18, 2003 at 12:56:15PM +0100, Julian Mehnle wrote:
> [EMAIL PROTECTED] wrote:
> > If we ever get a replacement libc that would really work as
> > replacement... on such system GNU claims would become much weaker.  Not
> > that there was a serious chance of that happening - drop-in replacement
> > of glibc on Linux would be a lot of work and so far none of the
> > alternative libc projects had tried to pull that off.
> 
> Why would anyone want to replace GLIBC in the first place?  To get rid of 
> "GNU" in "GNU/Linux"?

glibc has its problems and alternative libc implementations do exist (mostly
for embedded use), but AFAIK none of them tries to become a full-blown thing.

As for the reasons why somebody would do such replacement...  Beats me - ask
the guy who'd brought that up.  IMO it's very unlikely, to put it mildly.

Re: GNU within the name (Was: Changes in formal naming for NetBSD porting effort(s))

[viro]

On Thu, Dec 18, 2003 at 02:26:27PM +0200, Momchil Velikov wrote:
> > "Mathieu" == Mathieu Roy <[EMAIL PROTECTED]> writes:
> 
> Mathieu> If we follow your theory, it means that if someday another
> Mathieu> system use the glibc, we should remove the GNU from the
> Mathieu> GNU/Linux name.



Arrgh...

My apologies - I've managed to misparse the quote above.  Sorry.

OK...  That way it does make sense, but...  the rest of the arguments still
stands - libc has at least the same influence as the kernel and far more
than which implementation of cp(1), etc. is used on the system.

Anyway, that's far off-topic, so let's keep the followups off-list.
Apologies for misparsing.

Re: removing /etc/hotplug.d/ support

[Al Viro]

On Thu, Aug 25, 2005 at 01:09:14AM +0200, Marco d'Itri wrote:
> When I asked the udev maintainer about this, he replied that he does not
> believe that it will be an issue in the future.
> We are not even at the step of requiring udev for everything, only for
> less than ten packages which require some special hotplug support.

Aha, so I'll be able to carry sane forks of those.  Good to know - Debian
userland is nice for kernel work, would be a PITA to be forced to go looking
for replacement...


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]