winbindd_privileged permission issue

Bug #64425 reported by Nicola
Affects Status Importance Assigned to Milestone
samba (Ubuntu)

Bug Description

Binary package hint: winbind

I configured squid to use ntlm_auth to authenticate users against a Windows domain. To do this, the group ownership for directory /var/run/samba/winbindd_privileged needs to be changed from "root" to "proxy". No problem there, but of course 6.06 uses the varrun temporary filesystem to mount /var/run, so upon reboot the changes to the group ownership are lost.

I'm using this workaroud

cat /etc/init.d/

#set -x

chmodgrp() {
    chgrp proxy $WINBINDD_PRIVILEGED || return 1

case "$1" in
        echo "Error: argument '$1' not supported" >&2
        exit 3
        echo "Usage: $0 start|stop" >&2
        exit 3

update-rc.d start 21 2 3 4 5 .

can ubuntu team fix this issue?


Revision history for this message
Ante Karamatić (ivoks) wrote :

Snip from init script in gutsy:

case "$1" in
                log_daemon_msg "Starting the Winbind daemon" "winbind"

                mkdir -p /var/run/samba/winbindd_privileged || return 1
                chgrp winbindd_priv $PIDDIR/winbindd_privileged/ || return 1
                chmod 0750 $PIDDIR/winbindd_privileged/ || return 1
                start-stop-daemon --start --quiet --oknodo --exec $DAEMON -- $WINBINDD_OPTS

                log_end_msg $?

Does that solve the problem? Instead of proxy, we are using winbindd_priv group. On setting up, you should just add proxy user to winbindd_priv group.

Changed in samba:
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Jerome Haltom (wasabi) wrote :

I don't think this solution really works in my circumstance, which is that I use Winbind with PAM/NSS for *all* user's logons. Because my systems are joined to a domain and are standard desktop machines.

I would need to add *all* users to this group. This is not very practical.

It seems my use case of joining a machine to a Windows domain and expecting Windows users to be able to log in is pretty obvious.

Revision history for this message
Ante Karamatić (ivoks) wrote :

Ummm... no?

That's not solution, authentication and authorization is done by system (root), not users. You should add to this group only users under which some service is run - like squid.

winbindd(8) describes your setup under 'EXAMPLE SETUP', if that's what you had in mind.

Revision history for this message
Jerome Haltom (wasabi) wrote :

Except that's not true. All regular users must be able to look up their own record. Otherwise they cannot map their known uid to a displayable username. This happens all the time (everytime you run ls or ps, constantly by gnome applications themselves.)

Revision history for this message
Jerome Haltom (wasabi) wrote :

I take back what I previously said. NSS does not use this pipe, it uses another pipe I was unaware of.

Revision history for this message
Ready (d-ready) wrote :

To winbind to use, I have the user in the secondary group winbindd_priv added.
Now, have squid read right users on the folder /var/run/samba/winbindd_privileged.
Unfortunately, I do but still this error message "Ensure permissions on / var / run / samba / winbindd_privileged are set correctly."

now I have detect.

In squid, you do * not * specify the effective group id, instead you
Ensure the primary and supplementary groups for squid are squid
(Primary) and winbind_priv (secondary). At startup, will Squid
Initgroups () to get the right privileges.
The problem is now that Unbuntu set this value already as default on the group proxy.
For this reason, this problem arises.

Could the Ubuntu team fix this problem?

Revision history for this message
Thomas (t.c) wrote :

thats my quick fix:


start on started squid3


        chgrp -R proxy /var/lib/samba/winbindd_privileged/
        chgrp -R proxy /var/run/samba/winbindd_privileged/
end script

Revision history for this message
Thomas (t.c) wrote :

ok, this one is the right solution:

gpasswd -a proxy winbindd_priv

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.