From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935528AbcIPPSb (ORCPT ); Fri, 16 Sep 2016 11:18:31 -0400 Received: from vern.gendns.com ([206.190.152.46]:33797 "EHLO vern.gendns.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754064AbcIPPSX (ORCPT ); Fri, 16 Sep 2016 11:18:23 -0400 Subject: Re: [PATCH v3] leds: Introduce userspace leds driver To: Pavel Machek References: <1473439776-15655-1-git-send-email-david@lechnology.com> <80597ded-f4b4-2990-3eae-e72276296d1a@samsung.com> <20160915130831.GJ13132@amd> <313cbae5-fd66-f0ae-79a9-a3f4273d6f9c@samsung.com> <20160916055123.GB13205@amd> Cc: Jacek Anaszewski , Richard Purdie , linux-kernel@vger.kernel.org, linux-leds@vger.kernel.org, Marcel Holtmann From: David Lechner Message-ID: Date: Fri, 16 Sep 2016 10:18:22 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160916055123.GB13205@amd> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vern.gendns.com X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lechnology.com X-Get-Message-Sender-Via: vern.gendns.com: authenticated_id: davidmain+lechnology.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: vern.gendns.com: davidmain@lechnology.com X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/16/2016 12:51 AM, Pavel Machek wrote: > On Thu 2016-09-15 10:31:50, David Lechner wrote: >> On 09/15/2016 09:54 AM, Jacek Anaszewski wrote: >>> Hi Pavel, >>> >>> On 09/15/2016 03:08 PM, Pavel Machek wrote: >>>> Hi! >>>> >>>>>> + if (copy_from_user(&udev->user_dev, buffer, >>>>>> + sizeof(struct uleds_user_dev))) { >>>>>> + ret = -EFAULT; >>>>>> + goto out; >>>>>> + } >>>>>> + >>>>>> + if (!udev->user_dev.name[0]) { >>>>>> + ret = -EINVAL; >>>>>> + goto out; >>>>>> + } >>>>>> + >>>>>> + ret = led_classdev_register(NULL, &udev->led_cdev); >>>>>> + if (ret < 0) >>>>>> + goto out; >>>> >>>> No sanity checking on the name -> probably a security hole. Do not >>>> push this upstream before this is fixed. >>> >>> Thanks for catching this. >>> >>> David, please check if the LED name sticks to the LED class >>> device naming convention. >> >> I don't think it is a good idea to enforce the LED class naming convention. >> Someone may have a userspace application they want to test that has a >> hard-coded name that does not follow the convention. > > Umm. > > Noone has applications with hardcoded names that are not possible > today, right? > > And better not encourage crazy names. > > Best regards, > Pavel > Here is the actual `ls /sys/class/leds` from my Raspberry Pi: led0 pistorms:BA:red:ev3dev pistorms:BB:red:ev3dev pistorms:BA:blue:ev3dev pistorms:BB:blue:ev3dev pistorms:BA:green:ev3dev pistorms:BB:green:ev3dev Suppose I want to use uleds on my desktop to simulate my Raspberry Pi. If we restrict the name to the LEDs class convention of device:color:function, then I can't do this. led0 does not follow the convention at all. The other do follow the convention, but only if we allow that the device portion of the name can also include ':'. It's too late, the crazy names already exist.