[sslh] setsockopt: Operation not permitted when using init.d

Yves Rutschle yves at naryves.com
Sun Sep 22 14:47:05 CEST 2013


[Keeping the list in copy -- this is important for
distribution maintainers]

On Sun, Sep 22, 2013 at 06:02:48AM -0500, Matt Okeson-Harlow wrote:
> I installed from git source.
>     sslh v1.15-21-ga168461
> 
> I did set the capabilities.
>     $ getcap /usr/sbin/sslh-fork
>     /usr/sbin/sslh-fork = cap_net_bind_service,cap_net_admin+ep
> 
> It works if I run it using sudo, but not if I run it using 
>     sudo /etc/init.d/sslh start

Oh I see, I misunderstood. Now I can reproduce the behavior
you're seeing.

Ok, when sslh starts as root and then switches user, it
loses the capabilities and so can't do transparent proxying
anymore. That's why it works when running it directly under
your UID (no setuid, no losing capabilities).

One way to fix it is to drop to the unprivileged user before
starting the process, e.g. in Debian 

start-stop-daemon -c sslh_user --start --quiet --pidfile $PIDFILE --exec $DAEMON --test > /dev/null \
                || return 1           

Another way to fix it would be to change sslh to explicitely
retain capabilities across setuid, but I'm not fond of that
as that means sslh will end up with cap_net_admin under
unprivilege user without the administrator explicitely
knowing that. Plus, adding -c sslh_user is less work for me :D

Cheers,
Y.



More information about the sslh mailing list