LightDM does not build on Solaris because Solaris does not have the setresuid or setresgid functions. These are used in the file /src/privileges.c. If I #ifdef out these calls, the LightDM code otherwise builds okay. Is the use of these functions necessary? Would it make sense to #ifdef the code so it can also build and work on Solaris? Any advice about how to make this code more portable would be appreciated. Brian
These are required because there are cases where the root daemon process needs to access files in user directories. This is to avoid various security problems with symlinks. Does Solaris have something equivalent to drop the privileges? If we can detect existence of these function then we should conditionally use them or just have an #ifdef SOLARIS. On 29 November 2011 10:57, Brian Cameron <brian.cameron at oracle.com> wrote:> > LightDM does not build on Solaris because Solaris does not have the > setresuid or setresgid functions. ?These are used in the file > /src/privileges.c. ?If I #ifdef out these calls, the LightDM code > otherwise builds okay. > > Is the use of these functions necessary? ?Would it make sense to #ifdef > the code so it can also build and work on Solaris? ?Any advice about how > to make this code more portable would be appreciated. > > Brian > _______________________________________________ > LightDM mailing list > LightDM at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/lightdm >
* Brian Cameron <brian.cameron at oracle.com> [2011-11-29 01:58]:> > LightDM does not build on Solaris because Solaris does not have the > setresuid or setresgid functions. These are used in the file > /src/privileges.c. If I #ifdef out these calls, the LightDM code > otherwise builds okay. > > Is the use of these functions necessary? Would it make sense to #ifdef > the code so it can also build and work on Solaris? Any advice about how > to make this code more portable would be appreciated.privileges_drop() is being called from the lightdm daemon running with root privileges, so manipulating real and effective uid/gid without side effects on the saved uid is possible via procfs, ie. /proc/<pid>/ctl. Restoring them later in privileges_reclaim should be possible by first calling setuid() for setting the effective to the saved and then setreuid() for setting the real to the effective uid (and analoguosly calling setgid()/setregid() for restoring the effective/real gid). -- Guido Berhoerster