Description of problem: When I print to a cups printer that is actually a samba print queue on a remote server, setroubleshoot complains. Version-Release number of selected component (if applicable): cups-1.2.12-4.fc7 cups-libs-1.2.12-4.fc7 samba-3.0.26a-0.fc7 samba-client-3.0.26a-0.fc7 samba-common-3.0.26a-0.fc7 samba-swat-3.0.26a-0.fc7 selinux-policy-2.6.4-43.fc7 selinux-policy-targeted-2.6.4-43.fc7 How reproducible: From both openoffice calc and gedit, since F7 install {possible F6}. Steps to Reproduce: 1. start app. 2. open doc 3. print to remote samba queue Actual results: File is printed OK. setroubleshoot notifies of issue. Expected results: File is printed OK. Additional info: fsck filesystems and relabelled, but still occurs. Remote samba print server is Fedora Core 3, running an samba.org samba 3.0.24 built on the FC3 machine.
Created attachment 214671 [details] calc|gedit|calc print selinux preventing access errors
Is this a setup problem? This would not be allowed in rawhide either? How does smbspool communicate with tmp sockets?
As far as I know smbspool shouldn;t use sockets for anything, and the name of the file does not ring any bell here. It would be interesting to see a strace to understand what creates the socket and when it is used.
Could it be get_ticket_cache() looping over the files in /tmp looking to see if they are KRB5 tickets?
If this is doing the equivalent of an ls -l /tmp, yes
Yeah that could be. I think we already discussed in another bug report that smbspool searches for files starting with krbcc_ in /tmp. So it lists the /tmp directory to search for these files.
And when it finds them, I suppose it reads them?
Not necessarily, first of all the name must match the prefix, ie it should match /tmp/krbcc_, and this file does not match. Then it stat the file to see if it it of the right owner. Then it just sets the KRB5CCNAME env variable with that name. Therefore the file is read by the kerberos lib but only if kerberos auth is requested. I still don't know why this file is being read at all ...
It's not trying to read it I think. The failure is 'getattr', i.e. stat. (Dan: is that right?)
The tool is doing a getattr on all files in /tmp. A couple of files are sock_files which selinux policy does not allow. I have changed these to a dontaudit. Then I have given smbspool/cups the ability to read a kerberos credential cache if it needs it. Fixed in selinux-policy-2.6.4-47.fc7.src.rpm Currently rules are allowing cups to read /tmp eventually I will add policy for smbspool to read them and remove this from cup. BTW, Nalin was not thrilled with the way this works...
... because (aside from it just being icky) with the new keyring ccache support, you've got no guarantee that the user's credentials are even stored in files on the filesystem. They may be in the kernel keyring attached to the user's session.
The problem here is that cups need to be modified to understand kerberos, and to pass on users credentials. There is for sure a lot of space for improvement, but so far I think this was the quick and dirty way to have "something".
I think the 'auth-info-required' bits in CUPS are for that.
Do you know how the credentials would then be passed to the smbspool script ?
I think the CUPS backend gets restarted with AUTH_USERNAME/AUTH_DOMAIN/AUTH_PASSWORD in the environment. The 'ipp' backend (cups-1.3.*/backend/ipp.c) has an example of this.
Well, but we don't care about passwords, we already support password authentication (but in an ugly way :-/). We are talking about Kerberos and using the user's ticket to authenticate to a remote printer. Unless CUPS libs have a method to pass user/ccache file or memory, do you know if there is any support for non-password based authentication mechanisms in CUPS libs?
Ah, you need to set auth-info-requested to 'negotiate', and then the backend gets restarted with KRB5CCNAME=FILE:%s in the environment where %s is the actual file. None of this seems to be documented terribly well. :-(
With: cups-1.2.12-5.fc7 cups-libs-1.2.12-5.fc7 hal-cups-utils-0.6.9.2-1.fc7 libgnomecups-0.2.2-8 libselinux-2.0.14-9.fc7 libselinux-devel-2.0.14-9.fc7 libselinux-python-2.0.14-9.fc7 samba-3.0.26a-4.fc7 samba-client-3.0.26a-4.fc7 samba-common-3.0.26a-4.fc7 samba-swat-3.0.26a-4.fc7 selinux-policy-2.6.4-48.fc7 selinux-policy-targeted-2.6.4-48.fc7 The selin policy from updates-testing seems to have done the trick. An aside: if samba knows it is looking for files matching xxxxyyyy, would it ease selins action to have samba getattr only those files ? Or maybe it doesn't work like that ?