On Wednesday 06 December 2006 16:55, Matt Anderson wrote: > Eduardo Madeira Fleury wrote: > > Other than the issues you've raised here the only other thing I've > become aware of is when an auid is not available the client utilities > will block. Seems to me that they should return an error.
That's fine. > This appears to be the side effect of what went in for bug #213498. As > a result of that fix the MLS checks are not occurring when a user lists > the queue. I see, but, is that going to remain as a side effect or is that going to change? Besides MLS checks, I though one user was never allowed to see jobs from other users in the queue, even if they had the same levels. Does this requirement exist? > There was a fix related to this (bug #216855) that enabled FileDevice > printers. In testing what you mentioned above it seems that if the file > device file does not exists prior to attempting to print to it then the > action is blocked. In certain cases even when it does exist cupsd is > not allowed to stat() the target file. The error handling for that case > needs to be improved. Actually I had tried touching the printer device file to see what happened, and also tried to relabel that file in the same manner as /dev/usb/lp0. But the system might be outdated. I'll try to get any updates and test that again. > The main problem here is that if the file does not exist, then the cups > file backend needs to create it. I can add the logic to the file > backend to adjust the level and type of the file as necessary, or we can > document that in order to print to a file you must first `touch` that > file. I prefer the latter since although the level the file will be > obvious from the client's context the type will not be. user_lpr_t is a > typical type for the client, and while the user would be able to read > that output it still seems like the wrong type to me. > > If there are objections, or if someone knows of a good way to determine > what type the output should be then I can do that, but for now creating > the file before printing to it seems better to me. > > I will finish putting together an updated patch that addresses these > issues and send that to Redhat. > Thanks! -- Eduardo M. Fleury IBM Linux Technology Center Brazil Mobile: +55-19-81224410 email: [EMAIL PROTECTED] -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
