Subject: UBC turns EACCESS into EFAULT (e.g.: with NFS)
To: None <email@example.com>
From: Ignatios Souvatzis <firstname.lastname@example.org>
Date: 12/07/2003 16:33:07
Content-Type: text/plain; charset=us-ascii
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
[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
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
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
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: http://www.gnupg.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----