[Rpm-maint] [rpm-software-management/rpm] Make user/group info reliable operation across chroot (PR #2503)

[David Cantrell]

@dcantrell commented on this pull request.

Added some comments and questions.

>  #include <rpm/rpmlog.h>
 #include <rpm/rpmstring.h>
 
 #include "lib/misc.h"
 #include "lib/rpmug.h"
 #include "debug.h"
 
+#define PWFILE "/etc/passwd"
+#define GRPFILE "/etc/group"

I'm not aware of another system that would put passwd and group somewhere other than /etc, but then I think maybe CoreOS would and I'm sure MacOS X has a place like /private/etc or something like that.  Could these be defined in /usr/lib/rpm/macros or /usr/lib/rpm/rpmrc or is that too much yak shaving for unknown future proofing?  I personally like giving integrators the ability to adjust file locations at runtime if possible, but I know these are special files.

> +	    }
+	}
+    }
+
+    fclose(f);
+
+    return rc;
+}
+
+static int lookup_num(const char *path, const char *val, int vcol, int rcol,
+			long *ret)
+{
+    char *buf = NULL;
+    int rc = lookup_field(path, val, vcol, rcol, &buf);
+    if (rc == 0) {
+	long num = atol(buf);

Any reason to not use strtol() here?  In the error case here, doesn't atol() give you 0 which may or may not be fine.  But strtol() could catch errors for reporting here.

> +			long *ret)
+{
+    char *buf = NULL;
+    int rc = lookup_field(path, val, vcol, rcol, &buf);
+    if (rc == 0) {
+	long num = atol(buf);
+	*ret = num;
+	free(buf);
+    }
+    return rc;
+}
+
+static int lookup_name(const char *path, long val, int vcol, int rcol,
+			char **ret)
+{
+    char vbuf[256];

Where does 256 come from?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2503#pullrequestreview-1418656356
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/pull/2503/review/1418656356 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20230509/245fa185/attachment-0001.html>