The X-Y Problem, as it is sometimes called, is a logical fallacy which leads to enormous amounts of wasted time and energy, both on the part of people asking for help, and on the part of those providing help. It goes something like this:
- User wants to do X.
- User doesn't know how to do X, but thinks that he can fumble his way to a solution if he can just manage to do Y.
- User doesn't know how to do Y either.
- User asks for help with Y. Which, of course, is totally wrong because he really wants help with X. And Y isn't actually going to help him do that.
Here's an example.
<lhunath> when starting a process from shell, the process inherits the gid of the shell - I'm looking to start a process with a different GID than my own, so I assumed I should first newgrp to the new group and then start the process - however, newgrp audio gives the following error when run as non-root: Cannot execute bash: No such file or directory <lhunath> newgrp - audio works, however, but I can't use this in a shell script to start a certain process with a different GID since it spawns a subshell <greycat> What are you *really* trying to do? <lhunath> trying to start wine with GID of audio <greycat> lhunath: well... daemontools includes a setuidgid program that could do it, but to run that, you have to start out as root, and then define a user account whose primary group has the GID you desire. <greycat> I suspect what you *Really* want to do is "make wine's audio work". Which means you probably want to add yourself to group 'audio' in /etc/group, and logout and back in. <lhunath> grin, if only it were that easy. no, what I'm *really* trying to do is to get the rlimits that I set in pam for @audio to apply to the wineserver process so that it can use the sched_fifo to give audio threads a higher priority for games that request it. for wineserver to be able to use the rlimits, it needs to have a gid of the @audio that I defined in /etc/security/limits.conf <greycat> You don't actually think that rlimits magically "pop up" when a process is invoked with a specific UID/GID, do you? <greycat> rlimits are set within your *own* process and then handed down to your children when you fork/exec thme. <greycat> Only specific things read pam.d config files -- things that are linked with libpam. <greycat> Like /bin/login or /usr/sbin/sshd. <lhunath> greycat: should if I define '@audio - rtprio 90' in /etc/security/limits.conf ;x <greycat> lhunath: what process do you think reads that file? <lhunath> pam <lhunath> hrm. <greycat> lhunath: and you think that "wine" is linked with libpam? <greycat> you need to set the limits you want, *and then* run the program you want. <greycat> it will inherit them. <greycat> I do stuff like this all the time: su --> ulimit -v whatever --> su - freenet --> start the Freenet node <greycat> usually exec su - freenet, so that a raw root shell isn't left lying about if/when the freenet processes terminate <lhunath> heh. <goldfish> nice <greycat> See, *this* is why I ask things like "What are you really trying to do"