On Fri, Mar 20, 2009 at 1:13 PM, Jon Dowland
wrote:
> On Thu, Mar 19, 2009 at 12:34:44AM +0100, Bastien ROUCARIES wrote:
>> On Thu, Mar 19, 2009 at 12:21 AM, Luca Capello wrote:
>> > I would prefer any new information to be added there instead, since the
>> > files above are available offline as
On Thu, Mar 19, 2009 at 12:34:44AM +0100, Bastien ROUCARIES wrote:
> On Thu, Mar 19, 2009 at 12:21 AM, Luca Capello wrote:
> > I would prefer any new information to be added there instead, since the
> > files above are available offline as well.
>
> Does not forbid to add to wiki in order to ease
Steve Langasek wrote:
> However, I wonder if Marco isn't arguing on the basis of old information;
> lookups for LDAP at boot time should not result in long timeouts, and it's a
> bug in nss_ldap/libldap if they do - a bug which I thought had been
> addressed by now.
>
It still results in a numb
Josselin Mouette wrote:
> Le jeudi 19 mars 2009 à 11:09 +0100, Marco d'Itri a écrit :
>
>> How exactly? The problem is that these groups are referenced in the udev
>> configuration but do not exist, and this causes problmes at boot time
>> with systems using LDAP.
>>
>
> You mean, systems u
On Mar 19, Steve Langasek wrote:
> No, they should not. The system groups referenced by udev should instead
> always be present in /etc/group.
Correct.
> However, I wonder if Marco isn't arguing on the basis of old information;
Me too, the maintainers of the relevant packages are encouraged to
This one time, at band camp, Steve Langasek said:
> On Thu, Mar 19, 2009 at 11:37:59AM +0100, Bastien ROUCARIES wrote:
>
> > > But if the collective opinion of the project is that the issue does not
> > > exist then I will happily close bugs like #516149 and tell users to live
> > > with it. Pleas
Le jeudi 19 mars 2009 à 18:23 +0100, Marco d'Itri a écrit :
> Ignorance is not a point of view.
What if you explained *precisely* what is the problem you are seeing
with these groups, and the implications? If you keep referring vaguely
to discussions happening in other distributions instead, I fai
On Thu, Mar 19, 2009 at 11:37:59AM +0100, Bastien ROUCARIES wrote:
> > But if the collective opinion of the project is that the issue does not
> > exist then I will happily close bugs like #516149 and tell users to live
> > with it. Please advise.
> They should add this group to their ldap databa
On Thu, Mar 19, 2009 at 2:39 PM, Henning Glawe wrote:
> On Wed, Mar 18, 2009 at 07:13:22PM +0100, Marco d'Itri wrote:
>> This is the complete list of groups which I'd rather stop using:
>> rdma (infiniband devices)
>
> is there any alternative way to restrict access to infiniband
> without thi
On Thu, Mar 19, 2009 at 10:59 AM, Marco d'Itri wrote:
> On Mar 19, Bastien ROUCARIES wrote:
>
>> It is the same probleme with floppy, tty and disk group.
> No, it's not.
>
>> They should add this group to their ldap database. At least it should
> This would not change anything.
>
>> be documented
On Mar 19, Bastien ROUCARIES wrote:
> Moreover I respectfully disagree with you.? Permission on device file
Ignorance is not a point of view.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Wed, Mar 18, 2009 at 07:13:22PM +0100, Marco d'Itri wrote:
> This is the complete list of groups which I'd rather stop using:
> rdma (infiniband devices)
is there any alternative way to restrict access to infiniband
without this?
--
c u
henning
--
To UNSUBSCRIBE, email to debian-devel
Le jeudi 19 mars 2009 à 15:30 +0100, Marco d'Itri a écrit :
> > It looks to me that such setups are broken. Either they use /etc/group,
> > either they put these groups in their LDAP, but we can???t suddently start
> > supporting systems where important system groups are missing.
> They are not "im
On Mar 19, Josselin Mouette wrote:
> > How exactly? The problem is that these groups are referenced in the udev
> > configuration but do not exist, and this causes problmes at boot time
> > with systems using LDAP.
> You mean, systems using only LDAP and not the local /etc/group?
No.
> It looks
Le jeudi 19 mars 2009 à 11:09 +0100, Marco d'Itri a écrit :
> How exactly? The problem is that these groups are referenced in the udev
> configuration but do not exist, and this causes problmes at boot time
> with systems using LDAP.
You mean, systems using only LDAP and not the local /etc/group?
On Tue, Mar 17, 2009 at 11:42:52AM +0100, Marco d'Itri wrote:
> Users must not be in specific groups to access hardware, this is broken and
> insecure.
I was just about to reanimate my previous thread on better group handling for
squeeze, I think I'll put together a wiki page trying to summarize t
On Mar 19, Bastien ROUCARIES wrote:
> It is the same probleme with floppy, tty and disk group.
No, it's not.
> They should add this group to their ldap database. At least it should
This would not change anything.
> be documented that debian system need this group. BTW redhat has also
> rdma, fu
On Thu, Mar 19, 2009 at 11:09 AM, Marco d'Itri wrote:
> On Mar 19, Josselin Mouette wrote:
>
>> Once was thrown the idea to prefix all system groups with ???Debian-???.
> One of the most stupid ideas which have ever been inflicted on the
> project.
>
>> This solves this specific problem in a much
On Mar 19, Josselin Mouette wrote:
> Once was thrown the idea to prefix all system groups with ???Debian-???.
One of the most stupid ideas which have ever been inflicted on the
project.
> This solves this specific problem in a much better way.
How exactly? The problem is that these groups are re
Le mercredi 18 mars 2009 à 19:13 +0100, Marco d'Itri a écrit :
> fuse (I have no idea about how FUSE works)
Then why break it? It’s very useful to be able to restrict the list of
users allowed to use it.
OTOH, given how it works, it would be really useful to make it use D-Bus
so that we’d hav
m...@linux.it (Marco d'Itri) wrote:
Hi,
>> Scanner is useful, imagine I work in a company working on a secret
>> project. One of the computer has a scanner. Do you wnat to give
>> scanning right to the internship student ?
> No, I want to give access to the raw scanner device only to its own
> dr
I'd like to chime in with the general concern that the proposal to
remove a bunch of groups from udev seems under-baked and that the
current groups have value.
I definitely would like to see the tss (tpm) group remain along with
the kvm and fuse groups. I think scanner is important as well.
I ca
On Thu, Mar 19, 2009 at 12:21 AM, Luca Capello wrote:
> Hi there!
>
> On Wed, 18 Mar 2009 22:16:05 +0100, Bastien ROUCARIES wrote:
>> On Wed, Mar 18, 2009 at 9:38 PM, Bastien ROUCARIES
>> wrote:
>>> BTW instead of arguing about group and something like this could we
>>> create a wiki page on debi
On Mar 18, Bastien ROUCARIES wrote:
> Scanner is useful, imagine I work in a company working on a secret
> project. One of the computer has a scanner. Do you wnat to give
> scanning right to the internship student ?
No, I want to give access to the raw scanner device only to its own
driver-daemon
Hi there!
On Wed, 18 Mar 2009 22:16:05 +0100, Bastien ROUCARIES wrote:
> On Wed, Mar 18, 2009 at 9:38 PM, Bastien ROUCARIES
> wrote:
>> BTW instead of arguing about group and something like this could we
>> create a wiki page on debian wiki about justification of group.
>> Therefore purpose of ev
Bernd Zeimetz wrote:
Hi,
>> Yes, SCSI scanners still exist, and they're still used through
>> /dev/sgX. Actually, all high-volume, high-speed scanners are
>> SCSI. Some have a USB interface too, but it's slower.
>
> I also know some fancy damn expensive scanners with firewire, but I doubt
> they
Julien BLACHE wrote:
> m...@linux.it (Marco d'Itri) wrote:
>
> Hi,
>
>> This is the complete list of groups which I'd rather stop using:
>
>> scanner (do SCSI scanners still exist? how are they used?)
>
> Yes, SCSI scanners still exist, and they're still used through
> /dev/sgX. Actually, a
On Wed, Mar 18, 2009 at 9:38 PM, Bastien ROUCARIES
wrote:
> On Wed, Mar 18, 2009 at 7:23 PM, Bastien ROUCARIES
> wrote:
>> On Wed, Mar 18, 2009 at 7:13 PM, Marco d'Itri wrote:
>>> On Mar 18, Steve Langasek wrote:
>>>
A peek at the source says it uses /proc/acpi/ibm/light.
>>> Other people
On Wed, Mar 18, 2009 at 7:23 PM, Bastien ROUCARIES
wrote:
> On Wed, Mar 18, 2009 at 7:13 PM, Marco d'Itri wrote:
>> On Mar 18, Steve Langasek wrote:
>>
>>> A peek at the source says it uses /proc/acpi/ibm/light.
>> Other people told me that they believe that nowadays all modern
>> thinkpads use
On Tue, 17 Mar 2009, Bernd Zeimetz wrote:
> Please do not as it will allow users which need to access Thinkpad-specific
> devices (== /dev/nvram) access to /dev/{mem,kmem,port}. That's a huge security
> hole in my opinion.
Which are? If you mean people running tpb, tpb is as far as I know,
comple
t.
I *do* know of people still using the model 240, and those cannot use the
ACPI-based driver at all. But these people usually do NOT run Debian,
either.
However, if you remove group nvram, please don't go with kmem. Go with
root. While PeeCee CMOS-style NVRAM writes can soft-brick a box (
Bastien ROUCARIES wrote:
Hi,
>> scanner (do SCSI scanners still exist? how are they used?)
>
> Scanner is useful, imagine I work in a company working on a secret
> project. One of the computer has a scanner. Do you wnat to give
> scanning right to the internship student ?
Marco is specifical
m...@linux.it (Marco d'Itri) wrote:
Hi,
> This is the complete list of groups which I'd rather stop using:
> scanner (do SCSI scanners still exist? how are they used?)
Yes, SCSI scanners still exist, and they're still used through
/dev/sgX. Actually, all high-volume, high-speed scanners are
Bastien ROUCARIES wrote:
> On Wed, Mar 18, 2009 at 7:13 PM, Marco d'Itri wrote:
> Scanner is useful, imagine I work in a company working on a secret
> project. One of the computer has a scanner. Do you wnat to give
> scanning right to the internship student ?
Ack. That's what it the group is use
On Wed, Mar 18, 2009 at 7:13 PM, Marco d'Itri wrote:
> On Mar 18, Steve Langasek wrote:
>
>> A peek at the source says it uses /proc/acpi/ibm/light.
> Other people told me that they believe that nowadays all modern
> thinkpads use a kernel driver.
>
> This is the complete list of groups which I'd
On Wed, Mar 18, 2009 at 7:13 PM, Marco d'Itri wrote:
> On Mar 18, Steve Langasek wrote:
>
>> A peek at the source says it uses /proc/acpi/ibm/light.
> Other people told me that they believe that nowadays all modern
> thinkpads use a kernel driver.
>
> This is the complete list of groups which I'd
2009/3/18 Marco d'Itri :
> This is the complete list of groups which I'd rather stop using:
>
> fuse (I have no idea about how FUSE works)
Neither do I, I see FUSE helper binary is set suid, and executable
only for fuse members, but there could be more AFAIK. It would be a
good idea not to mes
On Mar 18, Steve Langasek wrote:
> A peek at the source says it uses /proc/acpi/ibm/light.
Other people told me that they believe that nowadays all modern
thinkpads use a kernel driver.
This is the complete list of groups which I'd rather stop using:
fuse (I have no idea about how FUSE work
On Wed, Mar 18, 2009 at 05:37:49PM +0100, Bernd Zeimetz wrote:
> > But I'm not aware of any reason that users need to access /dev/nvram,
> > generally. The only tool I know of that uses this interface is
> > hotkey-setup, which runs a daemon as root to handle polling the nvram state,
> > so the gr
Steve Langasek wrote:
> It's certainly far *more* insecure to add users to the kmem group than to
> the nvram group.
Definitely.
> But I'm not aware of any reason that users need to access /dev/nvram,
> generally. The only tool I know of that uses this interface is
> hotkey-setup, which runs a d
Stephen Gran writes:
>> Users must not be in specific groups to access hardware, this is broken
>> and insecure.
>
> That's the first I've heard that argument - of course you don't give
> untrusted users access to hardware, but we've always managed access to
> devices with group membership (lp, d
ts own, that's a fairly uninteresting rationale where system groups are
concerned.
> > utilities to work, you currently need to be in group nvram. Making that
> > equivalent to kmem seems unnecessarily broad to me.
> Users must not be in specific groups to access hardware, th
On Tue, Mar 17, 2009 at 05:12:36PM +0100, Marco d'Itri wrote:
> On Mar 17, Bernd Zeimetz wrote:
>
> > Please do not as it will allow users which need to access Thinkpad-specific
> > devices (== /dev/nvram) access to /dev/{mem,kmem,port}. That's a huge
> > security
> Other distributions apparentl
On Mar 17, Bernd Zeimetz wrote:
> Please do not as it will allow users which need to access Thinkpad-specific
> devices (== /dev/nvram) access to /dev/{mem,kmem,port}. That's a huge security
Other distributions apparently solved this.
--
ciao,
Marco
signature.asc
Description: Digital signatur
Le mardi 17 mars 2009 à 14:51 +0100, Luca Niccoli a écrit :
> >From policykit page:
> PolicyKit is specifically targeting applications in rich desktop
> environments on multi-user UNIX-like operating systems.
>
> Oh dear yes, another hal-like crap piece of software is just what we
> need the whole
2009/3/17 Marco d'Itri :
> E.g. cp /bin/bash .; chgrp audio bash; chmod g+s bash
I don't need to point out that this example doesn't make sense, do I?
> The rest of the Linux world is:
> http://dualstack.ipv6-exp.l.google.com/search?q=policykit .
>From policykit page:
PolicyKit is specifically
Marco d'Itri wrote:
> Unless somebody will have persuasive objections I will change it to
> group kmem in a future udev upgrade.
Please do not as it will allow users which need to access Thinkpad-specific
devices (== /dev/nvram) access to /dev/{mem,kmem,port}. That's a huge security
hole in my opi
Marco d'Itri wrote:
> On Mar 17, Stephen Gran wrote:
>
>> That's the first I've heard that argument - of course you don't give
> This is weird, because it has been around for quite a long time.
> E.g. cp /bin/bash .; chgrp audio bash; chmod g+s bash
This argument makes as much sense as
cp /bin/b
Le mardi 17 mars 2009 à 12:26 +0100, Marco d'Itri a écrit :
> > untrusted users access to hardware, but we've always managed access to
> > devices with group membership (lp, dialout, etc). Are you proposing
> > that should change?
> The rest of the Linux world is:
> http://dualstack.ipv6-exp.l.goo
This one time, at band camp, Marco d'Itri said:
> On Mar 17, Stephen Gran wrote:
>
> > That's the first I've heard that argument - of course you don't give
> This is weird, because it has been around for quite a long time.
> E.g. cp /bin/bash .; chgrp audio bash; chmod g+s bash
Since you can't d
On Mar 17, Stephen Gran wrote:
> That's the first I've heard that argument - of course you don't give
This is weird, because it has been around for quite a long time.
E.g. cp /bin/bash .; chgrp audio bash; chmod g+s bash
> untrusted users access to hardware, but we've always managed access to
>
This one time, at band camp, Marco d'Itri said:
> On Mar 17, Stephen Gran wrote:
> > This is the thinkpad /dev/nvram stuff, right? I thought for some tpctl
> > utilities to work, you currently need to be in group nvram. Making that
> > equivalent to kmem seems
ons.
>
> > utilities to work, you currently need to be in group nvram. Making that
> > equivalent to kmem seems unnecessarily broad to me.
> Users must not be in specific groups to access hardware, this is broken
> and insecure.
Like e.g. the audio and video groups ?
Mik
On Mar 17, Stephen Gran wrote:
> This is the thinkpad /dev/nvram stuff, right? I thought for some tpctl
I think so.
The rationale for this change is harmonization with all other
distributions.
> utilities to work, you currently need to be in group nvram. Making that
> equivalen
Hi Marco,
On Dienstag, 17. März 2009, Marco d'Itri wrote:
> Unless somebody will have persuasive objections I will change it to
> group kmem in a future udev upgrade.
Are you planning to file bugs against affected packages to help the
transition?
How will upgrades (from lenny, etch, ...) be han
This one time, at band camp, Marco d'Itri said:
> Unless somebody will have persuasive objections I will change it to
> group kmem in a future udev upgrade.
This is the thinkpad /dev/nvram stuff, right? I thought for some tpctl
utilities to work, you currently need to be in group nvr
Unless somebody will have persuasive objections I will change it to
group kmem in a future udev upgrade.
--
ciao,
Marco
signature.asc
Description: Digital signature
57 matches
Mail list logo
