Re: Seeking consensus for some changes in adduser
On Tue, Mar 08, 2022 at 12:29:43PM -0700, Sam Hartman wrote:
I don't think it makes sense to move toward 0700 home directories and to
loosen the umask for usergroups.
Those are actually unrelated--the big reason for the more permissive
umask is to allow people to seamlessly work with other people in a
group, especially within setgid shared directories. Those shared
directories can be anywhere, and are likely *not* in a single user's
home.
On Wed, Mar 09, 2022 at 09:00:14PM +0100, Marc Haber wrote:
On Tue, 8 Mar 2022 17:02:06 -0600, Richard Laager <rlaager@debian.org>
wrote:
I think the idea of dot in a username is perfectly reasonable on its
own. For some people this is very desirable. My wife, for example, uses
a dot in her email username as her first name plus my-now-her last
initial makes a word that is awkward. (This sort of problem is not
uncommon in usernames, especially at companies that make them via some
algorithm.)
I always use colon for chown, which is what is documented, but I'm aware
it takes dot too. Is there any code in chown to handle the dot case
intelligently?
How would chown handle the dot case intelligently? At the moment, the
chown manpage doesn't contain the words "dot" or "period", but chown
root.root some-file will do the same like chown root:root some-file,
changing user and group.
This was changed in coreutils to be posix-compliant more than 20 years
ago. The spec is that chown accepts user:group syntax, and chown will
always first attempt to split on ":". If there is no :, chown will try to
resolve the whole argument as a username (that is, regardless of whether
there's a "."). If the username isn't resolvable *and* it contains a
".", it will try to split on the first "." and use the left side as the
username and the right side as the group. So *only if* someone attempts
to use a dot-containing username in chown without a : and the
dot-containing username is invalid, then it might be interpreted as a
user.group spec. Now, if someone is trying to actually use user.group
syntax rather than the user:group syntax that's been standard for 20+
years, that will definitely break in the presence of dot-containing
usernames. Given how common such usernames are on other systems, I'd
expect the breakage to be minimal by now, and a bug in anything still
using that syntax. We could make coreutils print a deprecation warning,
but that's never really been useful in the past; probably better to just
error out any time a . is used for something other than a valid username
and drop the 20+ year old compatability code.
On Wed, Mar 09, 2022 at 02:35:52PM -0600, Richard Laager wrote:
Something along the lines of see if the user exists.
If I was to take a stab at an implementation (Python-ish pseudocode
here; yes I know chown is C):
group = None
if ':' in arg:
(user, group) = arg.split(':')
elif '.' in arg:
# This could be:
# user.group
# us.er.group
# user.gr.oup
# us.er.gr.oup
# Or user and/or group could have multiple dots.
# Idea A) Exactly one dot can mean either user.group or us.er
arg_split = arg.split(',', 2)
if len(arg_split) == 3:
# There was more than one dot.
user = arg
else:
# Split on dot.
(user, group) = arg.split('.')
if not getent(user):
# Treat the whole thing as a username.
user = arg
group = None
# Idea B) Loop over each possible split and see if any work.
I think this is much more fragile/less predictable than the current
behavior as the results will be dramatically different depending on the
exact combination of valid users & groups. Better to just make sure
you stick with the standard user:group representation.
Reply to: