Trying to start an X application (no matter which, try xeyes for instance) with only untrusted access yields: X Error of failed request: BadDrawable (invalid Pixmap or Window parameter) Major opcode of failed request: 55 (X_CreateGC) Resource id in failed request: 0x58 Serial number of failed request: 1 Current serial number in output stream: 4 This used to work with 6.9.0 for years, and it still seems to work with 7.2. An update to 7.3 breaks it; I can only start trusted clients with 7.3.
What is the use case here? Is this extension being used in production?
I have committed some changes to the xserver master branch that allow me to start an untrusted xeyes. The fix will be present in server 1.5 (but see below). Taking a look at server 1.4 now. The Security extension will be revised in 1.5. Untrusted clients will be treated slightly differently, so that not all accesses to trusted resources are denied, such as simply querying their presence. This was a result of the new XACE framework that provides finer-grained access modes than just read and write. The Security extension documentation will be updated to reflect the new semantics before the 1.5 release.
(In reply to comment #1) > What is the use case here? Is this extension being used in production? > Yes, I use that for production. I have a bunch of xterms that run with trusted access. Inside of each of these xterms runs a shell, and each shell process does *not* have trusted access. Also, many of these shell processes run under different user IDs. This way, I believe, these processes are pretty good separated from each other. Since I mostly use text-based applications, this yields a practical form of privilege separation on the desktop. However, sometimes I need to start a graphical application (e.g., to preview a PDF). I then start this application from one of the shell processes with *untrusted* access, in order that this graphical application (hopefully) cannot influence the xterms (which run trusted). This worked for me for years under 6.9.0. Recently, I switched to the 7.x series and discovered that this scheme was impossible to maintain under 7.3. I am now using 7.2, and it so far works just as fine aus 6.9.0 always did.
Pushed a fix to server-1.4-branch for the 1.4.1 release. Thanks for your feedback on use of that extension. I hope that some of the more advanced security solutions coming down the pike, such as SELinux, will eventually provide a superior solution for your use case. This is what my work to this point has been in support of.
(In reply to comment #4) > I hope that some of the more advanced security solutions coming down the pike, > such as SELinux, will eventually provide a superior solution for your use case. > This is what my work to this point has been in support of. > I am looking forward to the new security solutions. If there is any issue you would like me to test or comment on, please let me know.
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please file a new report if you continue to experience issues with a current server.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.