From: William Hubbs <w.d.hubbs@gmail.com>
To: Greg KH <greg@kroah.com>
Cc: kirk@braille.uwo.ca, speakup@braille.uwo.ca
Subject: Re: World writable speakup files in Linux next
Date: Fri, 10 Dec 2010 14:02:18 -0600 [thread overview]
Message-ID: <20101210200218.GA12830@linux1> (raw)
In-Reply-To: <20101210190047.GA19219@kroah.com>
Hi Greg and all,
If you are reading the speakup mailing list, and you reply to
this, please keep all addresses in the to and cc lines as they are and
do not drop anyone.
Greg, if you are not subscribed to the speakup list, they will not have
seen your original message, so this reply is the first message they will
see.
On Fri, Dec 10, 2010 at 11:00:47AM -0800, greg wrote:
> Hi all,
>
> In doing an audit of world writable sysfs files in the kernel tree, it
> turns out that the speakup subsystem has a lot of them.
>
> It's usually not a good idea to allow any user to write to sysfs files,
> unless you are really going to be able to handle it properly.
>
> As I don't want to just blindly remove the world writable permissions on
> all of these files, could someone go through and verify which ones
> should and should not be world writable?
I will look this over, but as far as I know, all of the world writable
files in the speakup sub system represent settings which we want to
allow the local user to change.
> Also remember, sysfs files can be set to be owned by specific users by
> udev, so the "local" user to the system can have things set to be
> writable by them if needed. But that happens in userspace, don't set
> the values as writable by any user by default from within the kernel.
I don't know anything about this feature in udev. Is it dynamic, e.g. if
I log into my system locally, would I be able to write to these files,
then if kirk were physically here and logged into my system, would he be
able to write to them?
We have discussed this on the speakup list before, but the only way we
knew of to get around it was to use a "speakup" group and make all of
the files owned by root and this speakup group. But, that group would
then have to have the same name for all linux distros, and I don't think
we want to go that route unless we have to.
I like what you are talking about, Greg, if it works the way I hope it
DOES -- being able to change the ownership of the sysfs files on the fly
based on who is logged in locally.
Can you show me a udev snippet that would allow this? If so, and we can
get it to work, what do we need to do to get it in the main udev
configuration?
Thanks,
William
next parent reply other threads:[~ UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20101210190047.GA19219@kroah.com>
` William Hubbs [this message]
` Frost
` Christopher Brannon
` William Hubbs
` Samuel Thibault
[not found] ` <20101212182940.GB16883@kroah.com>
` Kirk Reiser
` Samuel Thibault
` Kirk Reiser
` Samuel Thibault
` acollins
` Samuel Thibault
` Frost
` Samuel Thibault
` Kitty Litter
` Samuel Thibault
` Frost
` bardiazakeri
` Frost
` bardiazakeri
` Littlefield, Tyler
` bardiazakeri
` Kerry Hoath
` Littlefield, Tyler
` Arch Linux was: " Øyvind Lode
` bardiazakeri
` speakup and ubuntu, was: " Gregory Nowak
` Littlefield, Tyler
` Samuel Thibault
` Michael Whapples
` Samuel Thibault
` Frost
` bardiazakeri
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101210200218.GA12830@linux1 \
--to=w.d.hubbs@gmail.com \
--cc=greg@kroah.com \
--cc=kirk@braille.uwo.ca \
--cc=speakup@braille.uwo.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).