If you had followed my explanation, you would have come to this:

$ touch somefile; ls -ld $_ -rw-r--r-- 1 root root 0 May 5 21:25 somefile $ useradd lars $ groupadd vaessen $ chown lars.vaessen somefile && ls -ld somefile -rw-r--r-- 1 lars vaessen 0 May 5 21:25 somefile

$ rm somefile; touch $_; ls -ld $_ -rw-r--r-- 1 root root 0 May 5 21:25 somefile $ useradd lars.vaessen $ chown lars.vaessen somefile && ls -ld somefile -rw-r--r-- 1 lars.vae root 0 May 5 21:26 somefile

This is really not a telling example at all; it is more than a little contrived. If you have a situation like this then you are absolutely correct, if you do not it is a non-problem. You made a global statement of recommendation regarding: "a system chown you a file? It would go to the different user "lars" and the group "vaessen"." without an example like that you just gave. This is misleading and erroneous.

As you can see, the behaviour of chown depends on the contents of your /etc/passwd . So it's impossible to predict what would happen by deriving the commandline. And that's why you really do *not* want to use dots in usernames.

Also this is easily avoided at user generation time using a simple wrap for useradd. It is incorrect to say that it is "impossible" to predict what would happen. A bare bones proof of concept: awk -v xx="bogus.users" ' { if (m = split(xx,arr,".")) { FS = ":" if ($1 == arr[2]) { printf "%s", "You cannot use this name.\n" exit } } }' /etc/groups

...

...

If previous versions of yast didn't mind dots, they are broken. This is something that needs to be conclusively proven by real world examples of system malfunction arising from this use rather than an aesthetic dislike of the dotted seps.

I disagree in principle but you seem to be factually correct.

-- Johannes Franken

Professional unix/network development mailto:jfranken@jfranken.de http://www.jfranken.de/

-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here