[patch] alpha_strcpy for HEAD
i.viarheichyk at sam-solutions.net
Fri Jan 18 02:37:07 GMT 2002
On Fri, Jan 18, 2002 at 08:17:44PM +1100, Andrew Bartlett wrote:
> Ihar Viarheichyk wrote:
> > On Fri, Jan 18, 2002 at 09:09:06AM +1100, Andrew Bartlett wrote:
> > > What problem is this patch intended to solve?
> > >
> > > See my recent samba-technical post on my I think that this is a bad idea
> > > - the problem should be solved by certifying certain code-paths as
> > > 'stange char safe' rather than changing the definition of 'strange
> > > char'.
> > Current version of alpha_strcpy does not allow use non-ascii usernames,
> > it replaces them with "___". I don't see better way to solve this
> > problem than extend 'valid symbols' definition, as usernames are used in
> > %U substitutions (so this is surely not 'strange char safe' code path).
> > This patch just allow consider _all_ letters (including multibute ones
> > in e.g. UTF-8) as valid symbols.
> Can you tell me that all letters won't include \ ' / " * @ ! .. within
> that multibyte sequence?
> Can you tell me that they wont include a byte of value 255? That it
> won't inlude *any shell metacharacter*?
This depends on 'unix charset' parameter. UTF-8 will not include such
bytes. All single-byte encodings will not containg such characters,
while now single-byte non-latin letters are considered invalid.
I don't sure about Japaneese encodings, but think that if
Japaneese is used in the shell for e.g. filenames, it may be used safely
in usernames too.
> The better way to do this is to allow basic processing of 'unsafe'
> usernames, at least to the DC and to the username map. From this point
> we can take the usernames from a 'safe' source, that being what is
> recorded in the system. These are no longer 'tainted' and can be used
> for %u variable expansion without an issue. %U expansion could then
> occour on the munged version only.
> Andrew Bartlett
More information about the samba-technical