Re: suid, PAR:pp and disabling taint checks: pick any two of them

Create a non-root user. Set the group of your network devices to the group of this user (you might even get away with using the group 'root' for this user, makes things easier). Set the network devices to be group-writable. Use the script as this user (might even work to make the script suid to this user, but that could fire up taint checking too).

Or: Just use a group which you give to all your users (i.e. add all your users to the last column of this group in /etc/group). Users have to do 'newgrp <that group>' once in their shell and then can use the network devices if they have the same group. In that case everyone can use their non-root account and the script doesn't need suid since the user has the right to the devices anyway

Comment on Re: suid, PAR:pp and disabling taint checks: pick any two of them

Replies are listed 'Best First'.
Re^2: suid, PAR:pp and disabling taint checks: pick any two of them by azara (Initiate) on Oct 28, 2010 at 20:51 UTC
Thanks for that suggestion. I'd be happy to try that, but my impression is that I can not work around becoming root. The application uses Net::Pcap for packet capturing, and according to wireshark.org: Running Wireshark (or any other network capture/analyzer, for that matter) on Linux needs root privileges	[reply]
Re^3: suid, PAR:pp and disabling taint checks: pick any two of them by Anonymous Monk on Oct 29, 2010 at 12:43 UTC
Extract the part of the code that needs root privileges into a separate process. Make that taint-safe. Hopefully that's not very many lines but for sure it definitely isn't 50KLOC.	[reply]
Re^4: suid, PAR:pp and disabling taint checks: pick any two of them by azara (Initiate) on Oct 29, 2010 at 13:39 UTC
That's feasible, yes. Actually the packet capturing code is already located in a separate ithread (due to the script's Windows origins) - with ithread-specific communication via threads::shared etc. So that solution would require a re-design of the internal "IPC", extra code for managing the elevated process, and, worst of all - the script would no longer be portable... Any other ideas...? (I also opened a ticket on PAR::Packer - since a way to pass the standard "-UX" option to the Perl interpreter that's in a pp'ed binary would easily solve the problem... :-/ )	[reply]