Subject: UBC turns EACCESS into EFAULT (e.g.: with NFS)
To: None <>
From: Ignatios Souvatzis <>
List: tech-kern
Date: 12/07/2003 16:33:07
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


I've been debugging (at work) The Case of the Disappearing Crontab.=20
Long history at end, short history here:=20

errno is set to "Bad address" (EFAULT) when a suid-root program is trying
to read through an open file handle that the NFS server doesn't allow root
to read.

[I suspect the same would happen if you replace root by some other user.]

I suspect this happens because the original NFS EACCESS error is somehow
lost while being propagated through UBC ...

NFS / UBC experts: is it possible to propagate the original NFS error code
to the read system call exit? Actually - the same might happen if you read
a faulty (e.g. floppy) disk - reading EFAULT instead of EIO will be
confusing here, too. (I didn't test this.)


Long history, maybe interesting as background:

1. a paranoid user of mine has a script that reinstalls a couple
of files from a backup location, among them it executes

crontab ~/somepath/somefile

2. He reports that his installed crontab is empty at irregular intervals.

I told him to not throw away (>/dev/null 2>&1) the crontab output, but he
got no messages in the e-mail. I looked closer at the source code in
question, fixed error reporting for writing the intermediate file (on /var)
[see usr.sbin/cron/crontab.c 1.20], installed, and told him to recheck.

3. He reports no change and no error message.

4. I looked closer at the code, and found that -reading- errors wouldn't
be reported.

5. Also, my attention was drawn to his paranoid system admistrator who
only allows workstation root id to access fileserver NFS as nobody.

I added read error reporting code to crontab, did some tests, and found
that I get Bad address. (The fopen() succeeds because it is done with
swapped ids).

6. I told my user to use "/bin/cat hisfile | crontab - " as a workaround.

I'm build-testing my error reporting patch right now - we should at least
try to report a read error - but with our current (1.6) kernel behaviour,
this error message won't be helpful to the unsuspecting user.

seal your e-mail:

Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.3 (NetBSD)