[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Seeking consensus for some changes in adduser



On Thu, Mar 10, 2022 at 09:33:00PM +0100, Marc Haber wrote:
On Wed, 9 Mar 2022 17:29:01 -0500, Michael Stone <mstone@debian.org>
wrote:
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.

Hence, no change needed in adduser? Or is that an argument for having
DIR_MODE=0700 in default?

It's simply a statement that the default mode for home directories and the default umask are separate decisions.

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.

... but just in the case that the same string exists both as the last
component of a dot-containing user name AND as a group name. All other
cases are defined.

How would the spec listed above behave for user names with more than
one dot?

It splits on the first dot, which is why scripts could break. E.g., if you use user.group syntax and user happens to be us.er, then you end up trying to use us.er.group and that will fail. Semi-randomly, for whichever users happen to have dots, so it'll be a pain to debug.

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.

Do you want a coreutils bug to error out in the case of user.group
notation in chown? I guess it's due time. Would we go alone in Debian
or would you prefer that we try convincing upstream to finally go that
way? I am not convinced that Debian should derive from standard
behavior here, but you have the coreutils hat on and I would support
either decision.

I don't have a really strong preference either way. Maybe carry a patch until just before freeze to bubble stuff up during testing? Maybe allow an environment variable to override (either way?) to facilitate testing? The problem is that the systems most likely to blow up (because they're using ancient scripts) are also really unlikely to suddenly start using dot usernames, so breaking them for the sake of correctness on other systems seems gratuitous. If there isn't already, maybe some kind of lintian script check (though that seems probably challenging for static analysis)? In the end, there are already so many ways to shoot yourself in the foot with shell scripts if you don't follow all the disorganized rules every single time that letting this be the reason to disallow dot usernames seems extreme.


Reply to: