Greg Hudson wrote:
> On Mon, 2004-06-28 at 09:03, Josh Pieper wrote:
>
>>First, only symlinks are supported, however support for character
>>devices, block devices, sockets, and FIFOs would mostly be similar to
>>that for symlinks.
>
>
> I'm concerned about the security implications of allowing the server to
> instruct the client to create device files. So I'd say we should leave
> that out in the absence of (1) a clear demand, and (2) enough
> infrastructure so that the user has to explicitly turn on special device
> support in client-side configuration before it works.
>
Wouldn't standard OS permissions on the client take care of this? The client process runs with no greater priveledges than the
user running them, correct (the svn executable isn't setuid or setgid)? If the user can run the mknod command, how is letting svn
do the same any different?
If the sysadmin wants to remove the ability of users to create device special files, they should be mounting user-writable
filesystems with the nodev option. If they want to allow very specific access, then they would be making the mknod command not
runnable by root and allowing sudo access with specific arguments or creating a wrapper. And then they'd have to not allow the
user to compile programs, because they'll write their own programs that call the mknod system call. But even if you don't provide
your users compilers, are you also preventing them from uploading a compiler executable?
By all means don't add this functionality because of lack of demand, but I'm not sure security is a valid objection.
Cheers!
Bruce
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 29 02:37:48 2004