You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When I build and install as a non-root user, I would expect lppasswd to be executable but not setuid, so it would still be useful for root, at least. Root could also make it setuid later. This is what happens on Solaris, but on GNU/Linux, the GNU install program leaves a target file with mode 600 if it has trouble setting the ownership.
(Also, Solaris has trouble in man/Makefile:install - $(MAN3) is empty, and Solaris sh rejects "for file in ; do". An empty variable works, so you can use "man3='$(MAN3)'; for file in $$man3; do".)
The text was updated successfully, but these errors were encountered:
Sounds like a bug in GNU install; unfortunately, the "id" command (the only "universal" command for finding the current user) does not work the same on all OS's, so there is no easy way to check before installing with the setuid options. If we remove the setuid stuff, then we will break installs for a lot of people.
I might be able to add an executable test after installing lppasswd, and then chmod things if it isn't executable...
The second problem is already fixed for the next 1.1.21 release candidate.
Version: 1.1.21rc1
CUPS.org User: prj.po.cwru
When I build and install as a non-root user, I would expect lppasswd to be executable but not setuid, so it would still be useful for root, at least. Root could also make it setuid later. This is what happens on Solaris, but on GNU/Linux, the GNU install program leaves a target file with mode 600 if it has trouble setting the ownership.
(Also, Solaris has trouble in man/Makefile:install -$(MAN3) is empty, and Solaris sh rejects "for file in ; do". An empty variable works, so you can use "man3='$ (MAN3)'; for file in $$man3; do".)
The text was updated successfully, but these errors were encountered: