Bug 1936 - setuid/setgid/setcap programs do not work with local devices and homecreatefilter
Summary: setuid/setgid/setcap programs do not work with local devices and homecreatefi...
Status: ASSIGNED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Other (show other bugs)
Version: 1.4.1
Hardware: PC Linux
: P2 Normal
Target Milestone: MediumPrio
Assignee: Peter Åstrand
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-04-24 13:55 CEST by Peter Åstrand
Modified: 2024-04-15 09:30 CEST (History)
0 users

See Also:
Acceptance Criteria:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description Peter Åstrand cendio 2006-04-24 13:55:14 CEST 
This bug is transferred from comment #13 of bug 1538. When using
homecreatefilter with setuid applications, error messages like:

ERROR: ld.so: object 'libhomecreatefilter.so' from LD_PRELOAD cannot be
preloaded: ignored

...are printed. This is because when using setuid, preloading is only allowed
from "system directories" (/lib and a few others). Additionally, the library
must be setuid as well. 

One solution is to make sure libhomecreatefilter.so is setuid and placed in a
system directory. This will enable homecreatefilter for setuid applications. 

Even better, though, would be to have homecreatefilter ignored, without an error
message, for setuid applications. I don't know if this is possible, but I will
send a mail to the glibc mailing list and ask for help. 

Se also article 247818 in komintern.
Comment 1 Peter Åstrand cendio 2006-04-24 14:13:18 CEST 
Mail has been sent.
Comment 2 Peter Åstrand cendio 2008-01-14 16:50:42 CET 
I've generalized this bug somewhat. This is not just a problem of ugly error messages: On many systems both xterm and konsole are setgid and/or setuid. glibc does not only *ignore* "dangerious" variables: when it comes to LD_LIBRARY_PATH, it is completely removed. This means that if you start a xterm or konsole, LD_LIBRARY_PATH is no more. This means that:

* tl-run-rdesktop will not work, since libpcsclite.so cannot be loaded. 
* homecreatefilter is disabled
* serial port redirection is disabled

and so on. In particular, it's annoying that if you select "xterm" on the tl-select-profile menu, you will get an environment without the correct LD_LIBRARY_PATH. Some additional information:

* http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=328479 describes a similiar problem. 

* Another name for "system directories" is "trusted directories". 

* glibc loads libs from trusted dirs before using ld.so.conf, which is very annoying. This means that we cannot use ld.so.conf for our libpcsclite.so replacement. Very annoying. Other people thinks so as well, see http://cygwin.com/ml/libc-alpha/2001-08/msg00312.html. Also, as far as I know, it's not possible to determine at runtime which dirs are the trusted dirs. 

So, I think our approach is to continue setting LD_LIBRARY_PATH through vsmagent.conf, and use short names in LD_PRELOAD, but declare war at setuid/setgid applications. For example, tl-setup could warn if xterm/konsole are setuid/setgid.
Comment 3 Peter Åstrand cendio 2008-01-14 17:01:09 CET 
The tl-setup task is handled on bug 2620. This bug is for a more long-term solution, which perhaps involves glibc changes.
Comment 4 Pierre Ossman cendio 2020-06-16 10:05:34 CEST 
This also affects setgid and setcap programs. See bug 7517 for one major case.
Comment 5 Pierre Ossman cendio 2020-06-16 10:06:09 CEST 
Sorry, that should have been bug 7516.
Comment 6 Pierre Ossman cendio 2024-04-15 09:30:54 CEST 
pcsc-lite has added its own library redirection system, which could hopefully mitigate this issue for smart card redirection at least:

https://blog.apdu.fr/posts/2024/04/how-to-use-libpcsclite_delegate/
Note You need to log in before you can comment on or make changes to this bug.