linux-kernel - Re: [PWM PATCH 1/7] API to consolidate PWM devices behind a common user and kernel interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 09 Feb 2010 22:18:32 -0600
From:	Bill Gatliff <bgat@...lgatliff.com>
To:	H Hartley Sweeten <hartleys@...ionengravers.com>
CC:	linux-embedded@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PWM PATCH 1/7] API to consolidate PWM devices behind a common
 user and kernel interface

Bill Gatliff wrote:
>>> +
>>> +	p->requester = requester;
>>> +	if (!strcmp(requester, REQUEST_SYSFS))
>>> +		p->pid = current->pid;
>>>     
>>>       
>> This is new.. What's the reason for saving the pid?
>>   
>>     
>
> I've gotten complaints from those who say, "Ok, so it reported 'sysfs'
> back to me, but how can I be sure that it's because *I* own it now, and
> not another user process?"  Seemed easy enough to add the PID so they
> can check.  Of course, you could argue that I could report just the PID,
> and skip the "sysfs" string altogether.  I'd be inclined to agree with you.
>
> Of course, if you are like me and do the request with cat(1), then the
> PID is pretty meaningless.  :)
>   

For the record, this request activity is mostly advisory.  I can't
actually implement something where only the requester is subsequently
allowed to manipulate the state of the channel.  You really wouldn't
want to even if it was possible, because then you'd probably lose the
ability to control the output using cat(1) and echo(1).

I'm just trying to provide a tool that allows users to Play Nice if they
choose to.  In fact, it's currently possible to manipulate the state of
the channel from userspace without requesting ownership first.  Not sure
I'm happy with that, but since I can't enforce any sort of access
restrictions it seems pointless to even go so far as to require ownership...

b.g.

-- 
Bill Gatliff
Embedded systems training and consulting
http://billgatliff.com
bgat@...lgatliff.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/