On Wednesday 17 January 2007 12:01, Edi Weitz wrote:
On Wed, 17 Jan 2007 11:24:03 +0200, Nico de Jager ndj@hivsa.com wrote:
Form the Hunchentoot documentation: "On Unix you can use setuid and setgid to change the UID and GID of the process directly after the server has been started. (You might want to do this if you're using a privileged port like 80.) setuid and setgid can be integers (the actual IDs) or strings (for the user and group name respectively)."
Does this work on Linux?
Works for me - see below.
Will this change the uid and gid of the running lisp image or only of certain threads?
It calls setuid(2) and setgid(2) respectively which set the values "of the current process" - see the man pages.
In my instance, I start my LispWorks image as root in order to start the server on port 443, and then wish to change the Hunchentoot image to a uid/gid with less privileges. Supplying the :setuid and
:setgid parameters have no effect, though, the uid is still shown as
root with ps/top.
CL-USER 13 > (lisp-implementation-type) "LispWorks"
CL-USER 14 > (lisp-implementation-version) "5.0.1"
CL-USER 15 > (software-type) "Linux"
CL-USER 16 > (software-version) "2.6.17-2-686"
CL-USER 17 > (sys:call-system-showing-output "id") ; id ; uid=0(root) gid=0(root) groups=0(root) 0
CL-USER 18 > (hunchentoot:start-server :port 80 :setuid "edi" :setgid "users") #<HUNCHENTOOT::SERVER 200D45AF>
CL-USER 19 > (sys:call-system-showing-output "id") ; id ; uid=1000(edi) gid=100(users) groups=0(root) 0
CL-USER 20 > (hunchentoot:start-server :port 81)
Error: Failed to create socket. Syscall BIND failed: Permission denied (13). 1 (abort) Quit process.
Type :b for backtrace, :c <option number> to proceed, or :? for other options
I get the same reports back from the Lisp REPL using (sys:call-system-showing-output "id"), i.e. the uid/gid seems to have changed, but running ps or top from a bash prompt reports that the process is still owned by root: # ps aux .. root 9911 0.4 1.4 83976 29960 pts/8 Ss+ 12:42 0:02 /usr/local/bin/lispworks-console -init ~/.lispworks_console ..
I can probably test if this is really the case by doing something only root has privileges for.