Christian Perrier wrote:
Thanks a lot for investigating this. I vaguely remember coming on that
issue during my last samba bugs jihad last year..:-)
I don't know if you started a general bug triage on samba bugs, Jim,
but that would definitely be welcomed by the packaging team....even if
this is partial, that would be welcomed.
I'm not on any specific bug hunt per say.
I've just had issues with this permissions thing after an upgrade and it's
caused me a few late nights at work :)
I figured I'd report my findings to feed back into the process that helps keep
all the tools evolving and improving.
This is what I always do when I find any issues with an open source package :)
Finally as a compromise, and because I need to get NTLM working here at
work I settled on using SGID instead.
So my permissions are:
-rwxr-sr-x 1 root winbindd_priv 968848 Feb 6 15:45 /usr/bin/ntlm_auth
Still not the right solution I know; but gets me going with no risk of a
local user being able to get root access by exploiting a bug (if any) in
ntlm_auth.
So the interesting part is that squid doesn't seem to be picking up on the
secondary groups.
There seems to be a number of setuid, seteuid, setreuid, etc and their
equivalent gid system calls.
Perhaps squid is using the wrong one?
All this seem to anyway suggest that the bug is reassigned to the
squid package, doesn't it?
Squid's "bug" is that when it becomes the 'proxy' user it doesn't take on all
of 'proxy's secondary group privileges.
I'm not even sure if this is a bug really.
Maybe it's worth running this problem by the squid package maintainers (or the
upstream developers) and see what they think?
As to the bug being re-assigned to squid; possibly...
But it also shows that the winbind package's approach of using the
winbindd_priv group on the /var/run/samba/winbindd_privileged/ directory hasn't
quite worked as intended.
If squid was to "fix" the way it gains proxy's privileges, then this particular
problem would go away for the winbind package, until some other program that needs the
winbind pipe also uses the wrong system call.
Maybe the way ntlm_auth interacts with the winbind pipe needs to be
re-thought...
But I don't really have any solutions; unless that SGID one I have above is
suitable.
I suspect not since that means any local user on the system can run the
ntlm_auth process to do authentication requests against your Active Directory
server(s).
Regards,
----------
Jim Barber
DDI Health
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
