I posted the below question on the CUPS forums yesterday and have still not been able to find a good answer of why or if I can keep this from happening.
I have been looking for a while now and have still not found what I am looking for. Is there a way to allow multiple users to be updating the passwd.md5 file via the lpppasswd command? Everytime I make a change with user2 it overwrites the current user list that was made by user1. Also changes the ownership of the passswd.md5 file. Am I missing something or is there a way to allow multiple users to make changes that just update the file not overwrite the other users that were already in the digest file. Thanks in advance for help.
How exactly are you using this command? Show what you're doing word for word, letter for letter, keystroke for keystroke.
How exactly is it mangling the data in the file? Is it removing other users or something? Explain the changes it's doing that it shouldn't be.
That the ownership of the file keeps changing is odd. lppasswd is generally a setuid executable, meaning, runs as root and does its own security checking instead. So the ownership of the file ought to be the same all the time -- root.
I am using the following command to create users as part of the support group I created and am using in my cupsd.conf file. Everything works on the webgui the way I want so I am confident that is setup correctly. This is the syntax: /usr/bin/lppasswd -a -g support <username>. Both OS users that I have used to make changes are not the "Root" user but they both have lp as part of there groups. What happens is as follows. User1 will add user via lppasswd command above. That in turn changes the /etc/cups/passwd.md5 file ownership from root:lp to user1:lp. Then if I try and add a a user via lppasswd with user2 I overwrite the file and it moves what was in the file before to /etc/cups/passwd.old and now the ownership on the passswd.md5 file is user2:lp. Thoughts??? I have went through the cups documentation and have not found anything that is helpful.
It must be replacing the entire file, every single time. Nothing intrinsically wrong with that; some commands use it as a way to prevent two programs writing to the same file simultaneously. The changing ownership shouldn't matter as long as everyone involved can read and write to the lp group. As I mentioned, lppasswd is usually a setuid executable, which is perhaps why this behavior usually isn't noticed -- it'd always create files belonging to its own owner, not the users who call it...
You still have not described how you try to add users, just say that you do, so I can't say whether the way you're using lppasswd is right or wrong.
This is the syntax I use:
/usr/bin/lppasswd -a -g support user1
That is correct?
The information I have doesn't mention -s as an option for lppasswd.
I'm still not entirely clear on what your issue is. Are you complaining that when you add users, other users are removed?
I meant -g no -s. Sorry to many things going on here. Syntax: lppasswd -a -g support user1. Yes, my issue is when I add users with user2, user1's users are removed from the passwd.md5 file.
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.
<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.
# 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.)
1 Like
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.
-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.