Mailing List Archive

ls -alni /var/mail
Using the trial internal entropy gathering routines Damien so
kindly provided, I noticed stuff happening slowly. I think I've
traced this to the 'ls -alni /var/mail' taking a long time.

Given that this is likely to hurt a few sites similar to mine
(large number of users with an NFS-mounted /var/mail directory) is
it sensible to put a configure option in to disable this part?

I attach a patch to do this. It adds a configure option,
--without-lsmail. I'm not terribly happy with its name and I
haven't patched any of the docs.

Thanks,

Andrew Stribblehill
Systems Programmer, IT Service, University of Durham, England.
Re: ls -alni /var/mail [ In reply to ]
On Mon, 10 Apr 2000, Andrew Stribblehill wrote:

> Using the trial internal entropy gathering routines Damien so
> kindly provided, I noticed stuff happening slowly. I think I've
> traced this to the 'ls -alni /var/mail' taking a long time.

The entropy code is pretty peliminary. It could do with some
enhancements:

- Loading and saving of random seeds (per user and for server)

- A read timeout to prevent and errant process hanging ssh[d]

- The ability to load which commands to run from a text file

- Makefile support to sub the correct paths into the above text file

Any help would be greatly welcomed as I am pretty busy with Other
Things right now :)

-d

--
| "Bombay is 250ms from New York in the new world order" - Alan Cox
| Damien Miller - http://www.mindrot.org/
| Email: djm@mindrot.org (home) -or- djm@ibs.com.au (work)
Re: ls -alni /var/mail [ In reply to ]
I don't mind helping out here, I suspect I have some code from earlier
prng efforts that may be of use. Anyone else?

Have I read the seedfiles thing correctly? There is one seedfile for
sshd, and one each per user in the ~/.ssh directory. I think that raises
a few questions, IIRC similar to those from the prng discussion before:

- How should the sshd seedfile be protected?
- Should we consider the fact that we have multiple programs, oblivious
to each other, pulling entropy from the same sources?

I'm sure there are some other considerations too.

-Andre

Damien Miller wrote:
>
> On Mon, 10 Apr 2000, Andrew Stribblehill wrote:
>
> > Using the trial internal entropy gathering routines Damien so
> > kindly provided, I noticed stuff happening slowly. I think I've
> > traced this to the 'ls -alni /var/mail' taking a long time.
>
> The entropy code is pretty peliminary. It could do with some
> enhancements:
>
> - Loading and saving of random seeds (per user and for server)
>
> - A read timeout to prevent and errant process hanging ssh[d]
>
> - The ability to load which commands to run from a text file
>
> - Makefile support to sub the correct paths into the above text file
>
> Any help would be greatly welcomed as I am pretty busy with Other
> Things right now :)
>
> -d
>
> --
> | "Bombay is 250ms from New York in the new world order" - Alan Cox
> | Damien Miller - http://www.mindrot.org/
> | Email: djm@mindrot.org (home) -or- djm@ibs.com.au (work)
Re: ls -alni /var/mail [ In reply to ]
On Wed, 12 Apr 2000, Andre Lucas wrote:

> I don't mind helping out here, I suspect I have some code from
> earlier prng efforts that may be of use. Anyone else?

Thanks again.

> Have I read the seedfiles thing correctly? There is one seedfile for
> sshd, and one each per user in the ~/.ssh directory.

Correct.

> I think that raises a few questions, IIRC similar to those from the
> prng discussion before:
>
> - How should the sshd seedfile be protected?

1. mode 0600 and some checks to ensure that it is owned by the
correct user, etc.

2. RAND_add() it with a zero entropy estimate.

The main purpose of the seed file is to offset the problem posed in
your next question.

> - Should we consider the fact that we have multiple programs,
> oblivious to each other, pulling entropy from the same sources?

I agree that this is a problem. Part of the solution is ensuring that
there is a maximally wide variety of entropy sources and part of it
is the random seed mentioned above.

In the absence of kernel hooks to get timings, etc from hardware
events, the best we can do is rely on secondary sources. I don't see
this as much of a step back - EGD does much the same thing.

-d

--
| "Bombay is 250ms from New York in the new world order" - Alan Cox
| Damien Miller - http://www.mindrot.org/
| Email: djm@mindrot.org (home) -or- djm@ibs.com.au (work)