--tKW2IUtsqtDRztdT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello,

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.

Regards,
	-is
--=20
seal your e-mail: http://www.gnupg.org/

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQE/00gzPCRcZ/VMtk4RArVBAJ44WvcPX5+zgSu5+BgiHXY1nIEWdwCffYmg
U13gdWtY7xBDPAVaRk3iokM=
=9oCm
-----END PGP SIGNATURE-----

--tKW2IUtsqtDRztdT--