Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: [PATCH] compaudit: avoid defining a global getent fallback
- X-seq: zsh-workers 55239
- From: "Daniel Shahaf" <d.s@xxxxxxxxxxxxxxxxxx>
- To: "Xichen Zeng" <xichenzr@xxxxxxxxx>
- Cc: zsh-workers@xxxxxxx
- Subject: Re: [PATCH] compaudit: avoid defining a global getent fallback
- Date: Sun, 01 Nov 2026 12:50:46 +0000
- Archived-at: <https://zsh.org/workers/55239>
- Dkim2-signature: i=1; m=1; t=1793537466; d=daniel.shahaf.name; mf=PGQuc0BkYW5pZWwuc2hhaGFmLm5hbWU+; rt=PHpzaC13b3JrZXJzQHpzaC5vcmc+; s=fm1:rsa-sha256:qUwwlvVTqsLHAWLLhEDlUCuXvqgnGQ2TQXlDdlY5HuXyx0I 8Eyg7FLuVre4EEkv5c3JOfcy02iqXXtnYYou0vGNBmyGm34SQ5uTIKXDRuSGlqF2 79Pbd80ms2FDxSQ2eMmFESdmRuOoqZ2aRYqpgHx2CWeKhhRHJpEsIp7HA2kp194l m4jTRT7JC+gOU2Y7GhXsqbehIEpi3wSQ6Xq8iD0W4e3tvxufwuA+F5bhPVSNKysZ BLnGg9Yw5LgzJKv68hJxBw2WDAW39pF+4Be62yRjXZaLx9Osl/yM9AwQe7KBboHz 6n3HZGUpq8AVS98zNQZeI0nrQUzuWA85ZF9WdgQ==;
- Feedback-id: i425e4195:Fastmail
- In-reply-to: <c36ca4d0-8970-4e7a-a0ab-63b6b17cc0d7@gmail.com>
- List-id: <zsh-workers.zsh.org>
- Message-instance: m=1; h=sha256:XIkcXYJSdhg78A5nQrNEOeMnasCts80GSlriz++uLo0=:SilcRT8Jf5t3+ks8lqPUfXNu8cSTnUusFRo+VgEPZso=;
- References: <eeb3e2dc-51fc-46f1-b833-90740ed3a34e@gmail.com> <4255dff8-d002-4057-906f-beecaada64a9@app.fastmail.com> <c36ca4d0-8970-4e7a-a0ab-63b6b17cc0d7@gmail.com>
Xichen Zeng wrote on Sun, 01 Nov 2026 10:47 +00:00:
> Hi Daniel,
>
> Thanks for your review and suggestions.
>
> > Have you considered renaming the local «getent» function to, e.g.,
> > _compaudit_internal__getent, and then update the callsites to use that?
>
> Both callsites only query groups, so I renamed the helper to
> _compaudit_get_group and narrowed its interface to a group name or GID.
>
Nice!
> > This introduces an assumption that $LOGNAME is a valid group name (or
> > number), which is not correct on all systems. E.g., it's not correct on
> > www.zsh.org.
>
> The original code already calls `getent group $LOGNAME`.
Sorry, missed that.
> My
> understanding is that this checks for the user-private group special
> case: if no same-named group exists, the lookup fails and the exemption
> is not applied. I preserved that behavior and the original callsite
> branches, removing the intermediate _i_group variable.
Well, I'm not sure the whole "there's a group which happens to be named
the same as the username" special case makes sense at all. It seems to
me compaudit should only consider "What groups does X belong to?",
without regard to group names. (Of course, the the question is whether
X should be "the current process" or "the current user".)
Still, if this is an issue at all, it's an issue to be addressed in a
separate patch. The revised patch clearly doesn't change these
semantics one way or the other.
> Please let me know if I have missed another issue.
>
> > Shouldn't this codepath also be taken when a «getent» function is
> defined?
>
> Agreed. The helper now uses an existing getent command or function when
> available, falling back to /etc/group otherwise.
>
> I also added braces around the parameter expansions and changed the GID
> match to count fields from the start of the line, as suggested.
>
> The revised patch is attached.
>
Thanks! I *think* this is ready to merge, but I'll leave it for another
developer to review and do the honours.
Cheers,
Daniel
> Thank you,
>
> Xichen Zeng
> Attachments:
> * 0001-compaudit-use-a-private-group-lookup-helper.patch
Messages sorted by:
Reverse Date,
Date,
Thread,
Author