OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: Here's another glibc env. var.
From: Pavel Kankovsky (peakargo.troja.mff.cuni.cz)
Date: Thu May 25 2000 - 05:12:25 CDT

On Thu, 25 May 2000 haradaobunsha.co.jp wrote:

> You're removing needed functionality to get around programming errors.

No. I suggest to reduce functionality to discourage bad design. Complex
security-hazard-prone code, including (but not limited to) user interface
stuff, should be separated from code running with elevated privileges
that should be really small, simple, and paranoid.

On Thu, 25 May 2000, Solar Designer wrote:

> And I had to patch against 5.4.38 instead in order to be able to use
> elm where it needed SGID mail.

See above. :)

> I believe at least LC_CTYPE should be supported for SUID/SGID (LANG
> and LC_ALL should probably be limited to the functionality of
> LC_CTYPE if SUID/SGID),

The other guy advocated LC_MESSAGES.

> but restricted to not allow known control characters.

I'd prefer a fail-safe mode: restrict to known harmless characters.

> While we're on the topic, the ru_RU.KOI8-R locale in glibc 2.1.3
> thinks '\x80' through '\x9f' are printable characters.

This is correct. These characters are printable in KOI8 encoding (they
put PC semigraphic chars there).

> Perhaps there should also be an option to disable this, but it would
> have to be read from a file or such, which has a performance impact.
> Any suggestions?

I think the performance penalty would be negligible compared to existing
overhead (e.g. dynamic linking).

--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."