Red Hat

Please show your CUPS configuration related to the passwd.md5 file.

The cupsd.conf portion in relation to the cups digest password file is below. Although, I am not sure how this would affect how the ownership is being changed and how the file is being overwritten. If I was to just make changes with one user the everything works as I would expect. Unfortunately, we need to have the ability for multiple users to make changes.

Code:

<Policy default>
  <Limit >
    Order allow,deny
    Allow All
  </Limit>
  <Limit Cancel-Job CUPS-Move-Job Hold-Job Pause-Printer Purge-Jobs Release-Job Restart-Job Resume-Printer>
    AuthType BasicDigest
    Require user @support
  </Limit>
  <Limit All>
    Allow all
  </Limit>
</Policy>

Like I said, lppasswd is usually a setuid executable -- meaning, it would always be running as the same user no matter who called it. Perhaps that's why it's misbehaving.

Two obvious fixes:

1) sudo. Create a sudo rule which allows people in the lp group to call lppasswd as some other user. Doesn't have to be root. Then they do sudo -u username /usr/bin/lppasswd ... and it always runs as the same user.
2) If this is the only thing you use lppasswd for, you could make the lppasswd program setuid(as is traditional). Again, it doesn't have to be owned by root.

Code:

# In case you mess up the program somehow
tar -cf ~/lp-backup.tar /usr/bin/lppasswd
chown cups:lp /usr/bin/lppasswd
chmod u+x /usr/bin/lppasswd

Then it should always be called by the cups user. (Or whichever user you set it as.)

For now in my testing I took the advice of setting up sudo and I also had to apply the SUID on lppasswd for the user and the group to get it to work correctly. I appreciate all the help Corona.

Code:

-rwsr-sr-x 1 root lp 14640 Feb 25  2010 /usr/bin/lppasswd

Are you sure you need the group-sticky bit? I'm not sure what that even means, if anything, when running an executable...

If you're using sudo, you don't need setuid. If you're using setuid, you shouldn't need sudo. Combining both approaches is liable to be a big security hole.

You should remove read permissions for lp and world. Executable is enough.

If it doesn't work, please show exactly what you did.

After removing the setuid for user and group it still works fine with sudo. So that is probably my best option to keep things secure.

I agree, since you can be quite exact with who's allowed to do what with sudo, permission bits are rather coarse by comparison.