Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #175892 > unrolled thread

Preventing ACL on cdrom drive...

Back to article view | Back to linux.debian.user

Contents

  Preventing ACL on cdrom drive... Nimrod <nimrod@virgilio.it> - 2016-12-23 19:10 +0100
    Re: Preventing ACL on cdrom drive... "Thomas Schmitt" <scdbackup@gmx.net> - 2016-12-23 20:30 +0100
      Re: Preventing ACL on cdrom drive... Nimrod <nimrod@virgilio.it> - 2016-12-23 21:20 +0100
        Re: Preventing ACL on cdrom drive... "Thomas Schmitt" <scdbackup@gmx.net> - 2016-12-23 23:20 +0100
          Re: Preventing ACL on cdrom drive... Nimrod <nimrod@virgilio.it> - 2016-12-23 23:50 +0100
    Re: Preventing ACL on cdrom drive... Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-12-23 21:00 +0100
      Re: Preventing ACL on cdrom drive... Nimrod <nimrod@virgilio.it> - 2016-12-23 22:50 +0100
    Re: Preventing ACL on cdrom drive... Michael Biebl <biebl@debian.org> - 2016-12-24 05:30 +0100
      Re: Preventing ACL on cdrom drive... Nimrod <nimrod@virgilio.it> - 2016-12-26 17:30 +0100
        Re: Preventing ACL on cdrom drive... Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-12-26 18:40 +0100
          Re: Preventing ACL on cdrom drive... Nimrod <nimrod@virgilio.it> - 2016-12-26 22:20 +0100
            Re: Preventing ACL on cdrom drive... Nimrod <nimrod@virgilio.it> - 2016-12-28 11:30 +0100
              Re: Preventing ACL on cdrom drive... Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-12-28 13:50 +0100
                SOLVED Re: Preventing ACL on cdrom drive... Nimrod <nimrod@virgilio.it> - 2017-01-01 19:10 +0100

#175892 — Preventing ACL on cdrom drive...

[Multipart message — attachments visible in raw view] — view raw

Hi, 

sorry for this trivial question, but I really tried to find an answer on
the web without any result.

This is the issue: on a computer at home (shared among relatives, each
with his/her own account), the first user that logs in after boot locks
the cdrom drive, and any other user that logs in can't eject the cdrom:
only the first user can eject it.

Is there a way to avoid this? Being a home computer there are no privacy
issues: the cdrom drive is used just for CD ripping or burning, there's
no reason to prevent each other access to the unit.

Best regards.

-- 
Nimrod <nimrod@virgilio.it>

[toc] | [next] | [standalone]

#175893

Hi,

Nimrod wrote:
> the first user that logs in after boot locks the cdrom
> drive, and any other user that logs in can't eject the cdrom: only the first
> user can eject it.

Are you sure that it is the existence of the a user's ACL permission
which prevents the other's from ejecting and not their lack of own
permission ?

I understand from traces in the web, that on my Debian Jessie it is about
  SUBSYSTEM=="block", ENV{ID_CDROM}=="1", TAG+="uaccess"
in
  /lib/udev/rules.d/70-uaccess.rules
Rumor has it that "uaccess" causes the ACL.

The permission set of my /dev/sr0

  brw-rw----+ 1 root cdrom 11, 0 Dec 23 12:26 /dev/sr0

is not narrowed by the desktop user's ACL but rather widened. So i would
assume that your whole family needs rw-permission. That could be achieved
here by putting them all into group "cdrom".


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#175895

[Multipart message — attachments visible in raw view] — view raw

Thanks for your kind answer, below is mine.

On Fri, 2016-12-23 at 20:30 +0100, Thomas Schmitt wrote:

> Hi,
> 
> Nimrod wrote:
> > the first user that logs in after boot locks the cdrom
> > drive, and any other user that logs in can't eject the cdrom: only the first
> > user can eject it.
> 
> Are you sure that it is the existence of the a user's ACL permission
> which prevents the other's from ejecting and not their lack of own
> permission ?

No, I'm lost in the deepest darkness.

> 
> I understand from traces in the web, that on my Debian Jessie it is about
>   SUBSYSTEM=="block", ENV{ID_CDROM}=="1", TAG+="uaccess"
> in
>   /lib/udev/rules.d/70-uaccess.rules
> Rumor has it that "uaccess" causes the ACL.

That's what I found too, but none of the adviced solution works.

> 
> The permission set of my /dev/sr0
> 
>   brw-rw----+ 1 root cdrom 11, 0 Dec 23 12:26 /dev/sr0
> 

Here are mine:

brw-rw---- 1 root cdrom 11, 0 Dec 23 20:48 /dev/sr0

I see a "----+" in your permission. What is that, and how could I get it
too?


> is not narrowed by the desktop user's ACL but rather widened. So i would
> assume that your whole family needs rw-permission. That could be achieved
> here by putting them all into group "cdrom".
> 

They all are already.

I add something I forgot to mention: sometimes I'm even prompted for
password to eject a CD I myself put into the drive!

> 
> Have a nice day :)

I'd rather hope to get in bed quite soon and sleep till 11 AM, but
thanks a lot anyway.

> 
> Thomas
> 

[toc] | [prev] | [next] | [standalone]

#175898

Hi,

Nimrod wrote:
> I see a "----+" in your permission. What is that, and how could I get it too?

It indicates that there is a non-trivial ACL and that it is worth to run
program getfacl to see all permissions.

  $ getfacl /dev/sr0
  getfacl: Removing leading '/' from absolute path names
  # file: dev/sr0
  # owner: root
  # group: cdrom
  user::rw-
  user:<my desktop user name>:rw-
  group::rw-
  mask::rw-
  other::---

I.e. my desktop user explicitely has rw permission independently of his
group memberships.


> > putting them all into group "cdrom".

> They all are already.

Consider Pascal Hambourg's theory that only the one can eject who mounted.

If the automounter (udisks ?) acts on your desktop user's behalf or on
its own user id, then permissions on the device file might be not enough
to operate it.

In this case you need to get your automounter under control.


> sometimes I'm even prompted for
> password to eject a CD I myself put into the drive!

What happens if the various users perform the command

  eject /dev/sr0

in a shell terminal ? Especially the superuser should have success.

Maybe you can enable all your family members to perform
  sudo eject /dev/sr0
and provide some icon for this command on the desktop. (I assume family
does not like shell commands.)


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#175899

[Multipart message — attachments visible in raw view] — view raw

On Fri, 2016-12-23 at 23:16 +0100, Thomas Schmitt wrote:

> Hi,
> 
> Nimrod wrote:
> > I see a "----+" in your permission. What is that, and how could I get it too?
> 
> It indicates that there is a non-trivial ACL and that it is worth to run
> program getfacl to see all permissions.
> 
>   $ getfacl /dev/sr0
>   getfacl: Removing leading '/' from absolute path names
>   # file: dev/sr0
>   # owner: root
>   # group: cdrom
>   user::rw-
>   user:<my desktop user name>:rw-
>   group::rw-
>   mask::rw-
>   other::---
> 
> I.e. my desktop user explicitely has rw permission independently of his
> group memberships.
> 
> 
> > > putting them all into group "cdrom".
> 
> > They all are already.
> 
> Consider Pascal Hambourg's theory that only the one can eject who mounted.
> 
> If the automounter (udisks ?) acts on your desktop user's behalf or on
> its own user id, then permissions on the device file might be not enough
> to operate it.
> 
> In this case you need to get your automounter under control.
> 
> 
> > sometimes I'm even prompted for
> > password to eject a CD I myself put into the drive!
> 
> What happens if the various users perform the command
> 
>   eject /dev/sr0
> 
> in a shell terminal ? Especially the superuser should have success.

Here is what happens when another user issues the "eject" command:

umount: /media/andrea/CDROM: Permission denied
eject: unmount of `/media/andrea/CDROM' failed

As you surely expected, root can eject the cdrom instead.

> 
> Maybe you can enable all your family members to perform
>   sudo eject /dev/sr0
> and provide some icon for this command on the desktop. (I assume family
> does not like shell commands.)
> 

It would work, but that would also be rather unaesthetic. Nevertheless I
will try this approach as a last choice.

> 
> Have a nice day :)
> 
> Thomas
> 

[toc] | [prev] | [next] | [standalone]

#175894

Le 23/12/2016 à 18:54, Nimrod a écrit :
>
> This is the issue: on a computer at home (shared among relatives, each
> with his/her own account), the first user that logs in after boot locks
> the cdrom drive, and any other user that logs in can't eject the cdrom:
> only the first user can eject it.

I suspect that in order to eject the CD, you must first unmount its 
filesystem, but only the user who mounted it or root can unmount it if 
the CD drive has the "user" option in /etc/fstab. Try to replace "user" 
with "users" which allows any user to unmount it.

[toc] | [prev] | [next] | [standalone]

#175897

[Multipart message — attachments visible in raw view] — view raw

On Fri, 2016-12-23 at 20:54 +0100, Pascal Hambourg wrote:

> Le 23/12/2016 à 18:54, Nimrod a écrit :
> >
> > This is the issue: on a computer at home (shared among relatives, each
> > with his/her own account), the first user that logs in after boot locks
> > the cdrom drive, and any other user that logs in can't eject the cdrom:
> > only the first user can eject it.
> 
> I suspect that in order to eject the CD, you must first unmount its 
> filesystem, but only the user who mounted it or root can unmount it if 
> the CD drive has the "user" option in /etc/fstab. Try to replace "user" 
> with "users" which allows any user to unmount it.

There is no line about cdrom in /etc/fstab. Cdrom are usually mounted
under /media/<user>/cdrom or something like that. Since audio CD are not
mounted, any user can eject them. This could be a good point for your
suspicion (or is it "suspect"? Sorry, english is not my language).

Anyway, here is the output from mount about a CDROM:

/dev/sr0 on /media/andrea/CDROM type iso9660
(ro,nosuid,nodev,relatime,uid=1000,gid=1000,iocharset=utf8,mode=0400,dmode=0500,uhelper=udisks2)

Hope this is useful, thanks.


> 

[toc] | [prev] | [next] | [standalone]

#175902

[Multipart message — attachments visible in raw view] — view raw

Am 23.12.2016 um 18:54 schrieb Nimrod:
> Hi,
> 
> sorry for this trivial question, but I really tried to find an answer on
> the web without any result.
> 
> This is the issue: on a computer at home (shared among relatives, each
> with his/her own account), the first user that logs in after boot locks
> the cdrom drive, and any other user that logs in can't eject the cdrom:
> only the first user can eject it.
> 
> Is there a way to avoid this? Being a home computer there are no privacy
> issues: the cdrom drive is used just for CD ripping or burning, there's
> no reason to prevent each other access to the unit.

Does it help if you mount the cdrom as shared?
See https://udisks.freedesktop.org/docs/latest/udisks.8.html →
UDISKS_FILESYSTEM_SHARED

https://wiki.archlinux.org/index.php/udisks#Mount_to_.2Fmedia_.28udisks2.29



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[toc] | [prev] | [next] | [standalone]

#175949

[Multipart message — attachments visible in raw view] — view raw

On Sat, 2016-12-24 at 05:20 +0100, Michael Biebl wrote:

> Am 23.12.2016 um 18:54 schrieb Nimrod:
> > Hi,
> > 
> > sorry for this trivial question, but I really tried to find an answer on
> > the web without any result.
> > 
> > This is the issue: on a computer at home (shared among relatives, each
> > with his/her own account), the first user that logs in after boot locks
> > the cdrom drive, and any other user that logs in can't eject the cdrom:
> > only the first user can eject it.
> > 
> > Is there a way to avoid this? Being a home computer there are no privacy
> > issues: the cdrom drive is used just for CD ripping or burning, there's
> > no reason to prevent each other access to the unit.
> 
> Does it help if you mount the cdrom as shared?
> See https://udisks.freedesktop.org/docs/latest/udisks.8.html →
> UDISKS_FILESYSTEM_SHARED

No, it doesn't. The disk is already mounted in a shared directory, but
its name is "/media/<user>/CDROM", and permissions are restricted to
<user> only, where <user> is the one who first logged in the Gnome
desktop.

> 
> https://wiki.archlinux.org/index.php/udisks#Mount_to_.2Fmedia_.28udisks2.29
> 
> 
> 

[toc] | [prev] | [next] | [standalone]

#175955

Le 26/12/2016 à 17:28, Nimrod a écrit :
> On Sat, 2016-12-24 at 05:20 +0100, Michael Biebl wrote:
>
>> Does it help if you mount the cdrom as shared?
>> See https://udisks.freedesktop.org/docs/latest/udisks.8.html →
>> UDISKS_FILESYSTEM_SHARED
>
> No, it doesn't. The disk is already mounted in a shared directory, but
> its name is "/media/<user>/CDROM", and permissions are restricted to
> <user> only, where <user> is the one who first logged in the Gnome
> desktop.

/media/<user> is not a shared directory.

[toc] | [prev] | [next] | [standalone]

#175962

[Multipart message — attachments visible in raw view] — view raw

On Mon, 2016-12-26 at 18:29 +0100, Pascal Hambourg wrote:

> Le 26/12/2016 à 17:28, Nimrod a écrit :
> > On Sat, 2016-12-24 at 05:20 +0100, Michael Biebl wrote:
> >
> >> Does it help if you mount the cdrom as shared?
> >> See https://udisks.freedesktop.org/docs/latest/udisks.8.html →
> >> UDISKS_FILESYSTEM_SHARED
> >
> > No, it doesn't. The disk is already mounted in a shared directory, but
> > its name is "/media/<user>/CDROM", and permissions are restricted to
> > <user> only, where <user> is the one who first logged in the Gnome
> > desktop.
> 
> /media/<user> is not a shared directory.

Sorry, you're right. I followed the above suggestion, but the result is
not a great step forward: if another user tries to eject the cdrom, he's
asked with the password of the user who logged for first.

I guess I have to specify suitable permission in the above file. I tried
with:

ENV{ID_FS_USAGE}=="filesystem|other|crypto",
ENV{UDISKS_FILESYSTEM_SHARED}="1", GROUP="users", MODE="0660"

(on a single line), but it seems that GROUP and MODE are simply ignored.

Thanks a lot anyway.

> 

[toc] | [prev] | [next] | [standalone]

#176000

[Multipart message — attachments visible in raw view] — view raw

On Mon, 2016-12-26 at 22:16 +0100, Nimrod wrote:

> On Mon, 2016-12-26 at 18:29 +0100, Pascal Hambourg wrote: 
> 
> > Le 26/12/2016 à 17:28, Nimrod a écrit :
> > > On Sat, 2016-12-24 at 05:20 +0100, Michael Biebl wrote:
> > >
> > >> Does it help if you mount the cdrom as shared?
> > >> See https://udisks.freedesktop.org/docs/latest/udisks.8.html →
> > >> UDISKS_FILESYSTEM_SHARED
> > >
> > > No, it doesn't. The disk is already mounted in a shared directory, but
> > > its name is "/media/<user>/CDROM", and permissions are restricted to
> > > <user> only, where <user> is the one who first logged in the Gnome
> > > desktop.
> > 
> > /media/<user> is not a shared directory.
> 
> Sorry, you're right. I followed the above suggestion, but the result
> is not a great step forward: if another user tries to eject the cdrom,
> he's asked with the password of the user who logged for first.
> 
> I guess I have to specify suitable permission in the above file. I
> tried with:
> 
> ENV{ID_FS_USAGE}=="filesystem|other|crypto",
> ENV{UDISKS_FILESYSTEM_SHARED}="1", GROUP="users", MODE="0660"
> 
> (on a single line), but it seems that GROUP and MODE are simply
> ignored.

Sorry, I'm wrong again: the above line actually sets suitable permission
on /dev/sr0. So the problem is at mount point  level. The cdrom is
mounted under /media/CDROM, but whatever permission I give to /media the
CDROM subdirectory is owned by user 1000 and nobody can umount it except
user 1000 (that's me, but if another user mount it, "eject" prompts me
with my own credentials in order to actually eject the CDROM).

I didn't find any way to mount /media/CDROM avoiding this annoying
behaviour.

Deep darkness again.

> 
> Thanks a lot anyway. 
> 
> > 

[toc] | [prev] | [next] | [standalone]

#176005

Le 28/12/2016 à 11:19, Nimrod a écrit :
>
>> I guess I have to specify suitable permission in the above file. I
>> tried with:
>>
>> ENV{ID_FS_USAGE}=="filesystem|other|crypto",
>> ENV{UDISKS_FILESYSTEM_SHARED}="1", GROUP="users", MODE="0660"
>>
>> (on a single line), but it seems that GROUP and MODE are simply
>> ignored.
>
> Sorry, I'm wrong again: the above line actually sets suitable permission
> on /dev/sr0.

Anyway I do not think that it helps.

> So the problem is at mount point  level. The cdrom is
> mounted under /media/CDROM, but whatever permission I give to /media the
> CDROM subdirectory is owned by user 1000 and nobody can umount it except
> user 1000 (that's me, but if another user mount it, "eject" prompts me
> with my own credentials in order to actually eject the CDROM).

AFAIK, the ability for anyone to unmount the filesystem is not related 
to the permissions on the mount point but to the "users" mount option.

> I didn't find any way to mount /media/CDROM avoiding this annoying
> behaviour.

Mount with a line in /etc/fstab with options noauto,users.

[toc] | [prev] | [next] | [standalone]

#176212 — SOLVED Re: Preventing ACL on cdrom drive...

[Multipart message — attachments visible in raw view] — view raw

On Wed, 2016-12-28 at 13:42 +0100, Pascal Hambourg wrote:

> Le 28/12/2016 à 11:19, Nimrod a écrit :
> >
> >> I guess I have to specify suitable permission in the above file. I
> >> tried with:
> >>
> >> ENV{ID_FS_USAGE}=="filesystem|other|crypto",
> >> ENV{UDISKS_FILESYSTEM_SHARED}="1", GROUP="users", MODE="0660"
> >>
> >> (on a single line), but it seems that GROUP and MODE are simply
> >> ignored.
> >
> > Sorry, I'm wrong again: the above line actually sets suitable permission
> > on /dev/sr0.
> 
> Anyway I do not think that it helps.
> 
> > So the problem is at mount point  level. The cdrom is
> > mounted under /media/CDROM, but whatever permission I give to /media the
> > CDROM subdirectory is owned by user 1000 and nobody can umount it except
> > user 1000 (that's me, but if another user mount it, "eject" prompts me
> > with my own credentials in order to actually eject the CDROM).
> 
> AFAIK, the ability for anyone to unmount the filesystem is not related 
> to the permissions on the mount point but to the "users" mount option.
> 
> > I didn't find any way to mount /media/CDROM avoiding this annoying
> > behaviour.
> 
> Mount with a line in /etc/fstab with options noauto,users.

Well, actually that worked, but I was looking for a completely "udev"
solution. Nevertheless, I'm happy with this solution too, so I marked
the thread as solved.

Thanks and happy new year to everybody!

> 

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web