On Thu, Mar 19, 2009 at 12:34:44AM +0100, Bastien ROUCARIES wrote:
On Thu, Mar 19, 2009 at 12:21 AM, Luca Capello l...@pca.it 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
On Fri, Mar 20, 2009 at 1:13 PM, Jon Dowland
jon+debian-de...@alcopop.org 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 l...@pca.it wrote:
I would prefer any new information to be added there instead, since the
files
On Mar 19, Steve Langasek vor...@debian.org 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
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 using only
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 number
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
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
On Mar 19, Bastien ROUCARIES roucaries.bast...@gmail.com 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
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
On Thu, Mar 19, 2009 at 11:09 AM, Marco d'Itri m...@linux.it wrote:
On Mar 19, Josselin Mouette j...@debian.org 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
On Mar 19, Josselin Mouette j...@debian.org 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
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 Mar 19, Josselin Mouette j...@debian.org 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.
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 important
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
On Mar 19, Bastien ROUCARIES roucaries.bast...@gmail.com 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 Thu, Mar 19, 2009 at 10:59 AM, Marco d'Itri m...@linux.it wrote:
On Mar 19, Bastien ROUCARIES roucaries.bast...@gmail.com 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
On Thu, Mar 19, 2009 at 2:39 PM, Henning Glawe gla...@debian.org 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
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 database. At
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
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. Please advise.
Stephen Gran sg...@debian.org 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
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
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 group
On Mar 18, Steve Langasek vor...@debian.org 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
2009/3/18 Marco d'Itri m...@linux.it:
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
On Wed, Mar 18, 2009 at 7:13 PM, Marco d'Itri m...@linux.it wrote:
On Mar 18, Steve Langasek vor...@debian.org 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
On Wed, Mar 18, 2009 at 7:13 PM, Marco d'Itri m...@linux.it wrote:
On Mar 18, Steve Langasek vor...@debian.org 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
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 m...@linux.it 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
Bastien ROUCARIES roucaries.bast...@gmail.com 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
On Wed, 18 Mar 2009, Marco d'Itri wrote:
On Mar 18, Steve Langasek vor...@debian.org 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.
A driver which I happen to be the maintainer of
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,
On Wed, Mar 18, 2009 at 7:23 PM, Bastien ROUCARIES
roucaries.bast...@gmail.com wrote:
On Wed, Mar 18, 2009 at 7:13 PM, Marco d'Itri m...@linux.it wrote:
On Mar 18, Steve Langasek vor...@debian.org wrote:
A peek at the source says it uses /proc/acpi/ibm/light.
Other people told me that they
On Wed, Mar 18, 2009 at 9:38 PM, Bastien ROUCARIES
roucaries.bast...@gmail.com wrote:
On Wed, Mar 18, 2009 at 7:23 PM, Bastien ROUCARIES
roucaries.bast...@gmail.com wrote:
On Wed, Mar 18, 2009 at 7:13 PM, Marco d'Itri m...@linux.it wrote:
On Mar 18, Steve Langasek vor...@debian.org wrote:
A
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, all
Bernd Zeimetz be...@bzed.de 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
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
roucaries.bast...@gmail.com wrote:
BTW instead of arguing about group and something like this could we
create a wiki page on debian wiki about justification of group.
On Mar 18, Bastien ROUCARIES roucaries.bast...@gmail.com 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
On Thu, Mar 19, 2009 at 12:21 AM, Luca Capello l...@pca.it 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
roucaries.bast...@gmail.com wrote:
BTW instead of arguing about group and something like this could we
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
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 nvram. Making
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
On Mar 17, Stephen Gran sg...@debian.org 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
equivalent
On Tue, Mar 17, 2009 at 11:42:52AM +0100, Marco d'Itri m...@linux.it wrote:
On Mar 17, Stephen Gran sg...@debian.org 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.
This one time, at band camp, Marco d'Itri said:
On Mar 17, Stephen Gran sg...@debian.org 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 unnecessarily broad to
On Mar 17, Stephen Gran sg...@debian.org 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
This one time, at band camp, Marco d'Itri said:
On Mar 17, Stephen Gran sg...@debian.org 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
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:
Marco d'Itri wrote:
On Mar 17, Stephen Gran sg...@debian.org 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
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
2009/3/17 Marco d'Itri m...@linux.it:
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
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
On Mar 17, Bernd Zeimetz be...@bzed.de 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:
On Tue, Mar 17, 2009 at 05:12:36PM +0100, Marco d'Itri wrote:
On Mar 17, Bernd Zeimetz be...@bzed.de 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
On Tue, Mar 17, 2009 at 11:42:52AM +0100, Marco d'Itri wrote:
On Mar 17, Stephen Gran sg...@debian.org 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.
On its own, that's
56 matches
Mail list logo
