Hello, On Jun 27 13:32 Henrique de Moraes Holschuh wrote (shortened): > With the new "send it all over the socket in the first place" approach > hpiod, hpssd and the other components now take (which is much easier on us > trying to lock these things down, let me thank you again for switching to > this design even if it is potentially a bit slower than passing around file > handles or filenames in a spool), it should not be too difficult to even > move hpiod and hpssd to true network awareness, so that we could have the > tools talking to hpiod/hpssd on a remote server. This is the ultimate goal > for a GUI-less HPLIP packaging, IMHO.
If hpiod/hpssd become full network accessible services (i.e. accessible from other IPs than 127.0.0.1), we (i.e. the distributors or at least Suse/Novell) have the problem that network accessible services must not run as root because of obvious security reasons. This means that when there is full network support, it must be possible that the services can work as a non-root user (e.g. the usual "lp" user for printing services or perhaps an additional "scan" user for scanner access or perhaps a new "hp" user for all hpiod/hpssd access). Of course a distributor can and will make sure that the regular file and device node permissions are set accordingly so that those non-root user can access what it needs and only what it needs. On the other hand this does not mean that it must be impossible to run hpiod/hpssd as root. For example on a system in a trusted internal network it may be the easiest way to get it all working without thinking about permissions at all. For a self-compiled HPLIP it could be a usage-friendly but security-unfriendly default to run the services as root. It is your (i.e. HP's) decission what you prefer in this case: Be usage-friendly for the price of intrinsic insecurity or be security-friendly for the price of usage-problems. Note that I carefully distinguish between "user-friendly" and "usage-friendly" because an intrinsic insecure system is obviously never ever "user-friendly". Think about when crackers learn about that on systems with a self-compiled HPLIP there are network services runing as root and sooner or later there will be a successful attack and then it becomes known that it is HP who is to blame for hundreds of cracked systems because of insecure HP services ... Just an idea: Perhaps it is easiest to leave hpiod/hpssd running as root and keep it listening only on 127.0.0.1 and have an additional new hpproxy service which does not run as root and which listens on 0.0.0.0 on a fixed registred port? (There is no "hplip" at http://www.iana.org/assignments/port-numbers). Of course all sercurity related stuff must be done in hpproxy (e.g. check for allowed source IPs, do additional optional user authentication, check if data is valid, ...) because it wouldn't be more secure when hpproxy simply forwards any arbitrary stuff to hpiod/hpssd which are running as root. But this would ad least keep the non-localhost network stuff well seperated from the localhost network stuff. E.g. the user could simply stop hpproxy and there is no longer any non-localhost network stuff which he must worry about. And for a self-compiled HPLIP, hpiod/hpssd could still work as usual and hpproxy would not be activated by default so that even a self-compiled HPLIP would be o.k. on a home-user system. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5 Mail: [EMAIL PROTECTED] 90409 Nuernberg, Germany WWW: http://www.suse.de/ Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ HPLIP-Devel mailing list HPLIP-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hplip-devel
