Re: FR: NetworkManagerDispatcher should fireup scripts owned by any user.

[Hans Deragon <hans deragon biz>]

Aaron Konstam a écrit :
> On Sun, 2007-07-08 at 21:02 -0400, Hans Deragon wrote:
>> Greetings.
>>
>>
>>   [ Resending with a less annoying title and non signed email;
>>     Please reply to this email instead to start a thread.
>>     My apologies ]
>>
>>   I would like to propose a new feature.  The NetworkManagerDispatcher
>>   should call any scripts found under NM_SCRIPT_DIR (currently hardcoded
>>   to '/etc/NetworkManager/dispatcher.d' directory), regardless of the
>>   owner.  Currently, it only executes scripts owned by root.
> As usual, I am confused. In Fedora 7 there is no such directory. Are you
> on another Linux version.

Looks like a standard directory.  Ubuntu 7.04 and SuSE Linux Enterprise
Desktop 10 have it.  It is hard coded in:

NetworkManager-0.6.5/dispatcher-daemon/NetworkManagerDispatcher.c
#define NM_SCRIPT_DIR           SYSCONFDIR"/NetworkManager/dispatcher.d"

>>   Scripts would be executed with the EUID set to the user owning the
>>   script.  This would prevent a user to gain root privileges.  But with
>>   this feature, users without any admin privileges could add their own
>>   scripts.  For instance, they could set ssh tunnels when getting
>>   connected to a particular network.
>>
>>   NM_SCRIPT_DIR would have the sticky bit set, like /tmp.  From chmod
>>   man page:
>>
>>      When the sticky bit is set on a directory, files in that directory
>>      may be unlinked or renamed only by the directory owner as well as
>>      by  root or the file owner.  Without the sticky bit, anyone able to
>>      write to the directory can delete or rename files.  The sticky bit
>>      is commonly found on directories, such as /tmp, that are
>>      world-writable.
>>
>>   Comments are welcomed.
>>
>>   If my proposal is welcomed, I could give a try coding it and submit a
>>   patch.  Instead of calling system() directly, a fork would be
>>   executed, and the child would perform a setuid() call prior calling
>>   system().  One advantage of forking is that the daemon would never
>>   freeze since only the children would call shell commands.  Thus if a
>>   shell command loops indefinitely, the main daemon isn't affected.

Br,
Hans Deragon
http://www.deragon.biz        Open source (contribution):
mailto://hans deragon biz     http://autopoweroff.deragon.biz