Hi, r. a. schmied writes:
> Dr Rainer Woitok wrote: >> [...] >> >> Next I cloned the Git repository in order to be able to freely change >> between various versions to find one which is working for me by compil- >> ing "sane-backends" myself. [...] >> >> ./autogen.sh && ./configure >> >> I got two warnings which I do not quite understand: >> >> configure: WARNING: Group uucp does not exist on this system. >> configure: WARNING: Locking feature will be disabled. >> >> The group does in fact exist: >> >> $ ls -l /etc/group /etc/gshadow >> -rw-r--r-- 1 root root 755 2020-01-14 10:03 /etc/group >> -r--r----- 1 root root 622 2020-01-14 10:03 /etc/gshadow >> $ grep uucp /etc/group /etc/gshadow >> /etc/group:uucp:x:14:uucp >> /etc/gshadow:uucp:::uucp >> $ >> >> So what does that mean? Do "configure" and "make" want myself to be a >> memer of group "uucp" while I'm just compiling the stuff? > > rainer and saners > > on a solaris 10 sparc platform running sane-backends configure as > me (ras) results in the same warning even though group uucp does exist. > > the problem is in the os security permissions or lack thereof, at least > on sol10, and i would expect on a security conscience linux as well. > > i don't recall if running sane-backends configure is supposed to be > performed as root (i would hope and suspect not) but make install would be. Normally, running `./configure` as an unprivileged user is expected to work just fine. To run `make install` you would normally need elevated privileges. But in the end it all really depends on the system you run these commands. On my Devuan system, `/usr/local/` is group staff and has group write permissions. If my account is part of the staff group, I can run `make install` without root privileges (assuming the default prefix). > expert gnu autoconfigurers might be able to find a better way to > determine if group uucp does in fact exist and can be used by a sane > process instead of the current method: > touch sanetest.file > chgrp $LOCKPATH_GROUP sanetest.file 2>/dev/null || lasterror=$? Thanks for digging this up! It looks horribly broken as it will fail for any value of LOCKPATH_GROUP unless the user running `./configure` is a member of that group (or root as on our CI environments). Apart from that, I also think `uucp` is not really the right group for this. I think it should be the same group that is used to facilitate I/O with local devices. This is distribution dependent but typically `scanner` or `lp`. Anyway, I'll deal with this in #235. Hope this helps, -- Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Software https://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join
