Re: [gentoo-dev] useless set*id binaries

[Ulrich Mueller]

 On Sat, 28 Jan 2012, Samuli Suominen wrote:

 This is definitely not an improvement and should be reverted. The
 suid root is also needed to elevate cdrecord's scheduling priority.

 Missed that piece of code and reverted then. Any chance you could be
 more specific?

cdrecord calls mlock(2), setpriority(2), and sched_setscheduler(2) to
lock itself in memory and set realtime scheduling (and after having
done so, it of course resets its uid to non-root).

And yes, it really makes a difference on a moderately loaded machine.
(Having written data from physics experiments to thousands of
CDs/DVDs/Blurays, I think I can claim some experience here.)

With file based capabilities, one could set CAP_IPC_LOCK and
CAP_SYS_NICE instead of the suid root.

Re: [gentoo-dev] useless set*id binaries

[Michał Górny]

On Sat, 28 Jan 2012 03:07:45 +0200
Samuli Suominen ssuomi...@gentoo.org wrote:

 On 01/28/2012 02:41 AM, Mike Frysinger wrote:
  On Friday 27 January 2012 19:18:07 Samuli Suominen wrote:
  On 01/28/2012 02:14 AM, Mike Frysinger wrote:
  along these lines, why is cdrtools set*id ?  if we have a cdrom
  group, and we assign our cdroms/dvdroms to that group, then we
  already have access control in place and can skip the set*id.
 
  cdrtools can't probe the drives without the binary being setuid,
  or the user belonging to the 'disk' group (and even that is not
  enough in some cases if the permissions vary)
 
  the drives are owned by the cdrom group and have group +rw.  so
  if the user is in the cdrom group, why can't they probe the
  drives ?
 
  disk owns the non-removable hard drives.
 
  $ ls -l /dev/sr0 /dev/sg0 /dev/sg6
  crw-rw 1 root disk  21, 0 Jan  6 23:07 /dev/sg0
  crw-rw 1 root cdrom 21, 6 Jan  6 23:07 /dev/sg6
  brw-rw 1 root cdrom 11, 0 Jan 17 22:28 /dev/sr0
  -mike
 
 i dont know why, but it does probe also non-removable disks... it
 probes per bus, iirc
 
 you can try it easily yourself:
 
 ssuominen@null ~ $ cdrecord -scanbus

Does user actually need to be able to do this? Doesn't passing dev=...
directly work?

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] useless set*id binaries

[Samuli Suominen]

On 01/28/2012 10:32 AM, Michał Górny wrote:

On Sat, 28 Jan 2012 03:07:45 +0200
Samuli Suominenssuomi...@gentoo.org  wrote:


On 01/28/2012 02:41 AM, Mike Frysinger wrote:

On Friday 27 January 2012 19:18:07 Samuli Suominen wrote:

On 01/28/2012 02:14 AM, Mike Frysinger wrote:

along these lines, why is cdrtools set*id ?  if we have a cdrom
group, and we assign our cdroms/dvdroms to that group, then we
already have access control in place and can skip the set*id.


cdrtools can't probe the drives without the binary being setuid,
or the user belonging to the 'disk' group (and even that is not
enough in some cases if the permissions vary)


the drives are owned by the cdrom group and have group +rw.  so
if the user is in the cdrom group, why can't they probe the
drives ?

disk owns the non-removable hard drives.

$ ls -l /dev/sr0 /dev/sg0 /dev/sg6
crw-rw 1 root disk  21, 0 Jan  6 23:07 /dev/sg0
crw-rw 1 root cdrom 21, 6 Jan  6 23:07 /dev/sg6
brw-rw 1 root cdrom 11, 0 Jan 17 22:28 /dev/sr0
-mike


i dont know why, but it does probe also non-removable disks... it
probes per bus, iirc

you can try it easily yourself:

ssuominen@null ~ $ cdrecord -scanbus


Does user actually need to be able to do this? Doesn't passing dev=...
directly work?



It will work if you specify it by hand. But how do you know without 
using -scanbus what to specify?


Also, burning frontends, such as xfburn, rely on this functionality to 
automatically find the burner when USE=udev is disabled.


And if I don't remember wrong, k3b also uses it as fallback method.

Re: [gentoo-dev] useless set*id binaries

[Samuli Suominen]

On 01/28/2012 02:14 AM, Mike Frysinger wrote:

hmm, i wonder why mount.nfs is set*id.  if we require everyone to use `mount`,
there's no need for `mount.nfs` to be set*id.  someone want to point out
something obvious that i'm missing before i adjust the nfs-utils package ?

along these lines, why is cdrtools set*id ?  if we have a cdrom group, and
we assign our cdroms/dvdroms to that group, then we already have access
control in place and can skip the set*id.
-mike


cdrtools can't probe the drives without the binary being setuid, or the 
user belonging to the 'disk' group (and even that is not enough in some 
cases if the permissions vary)

Re: [gentoo-dev] useless set*id binaries

[Mike Frysinger]

On Friday 27 January 2012 19:18:07 Samuli Suominen wrote:
 On 01/28/2012 02:14 AM, Mike Frysinger wrote:
  along these lines, why is cdrtools set*id ?  if we have a cdrom group,
  and we assign our cdroms/dvdroms to that group, then we already have
  access control in place and can skip the set*id.
 
 cdrtools can't probe the drives without the binary being setuid, or the
 user belonging to the 'disk' group (and even that is not enough in some
 cases if the permissions vary)

the drives are owned by the cdrom group and have group +rw.  so if the user 
is in the cdrom group, why can't they probe the drives ?

disk owns the non-removable hard drives.

$ ls -l /dev/sr0 /dev/sg0 /dev/sg6
crw-rw 1 root disk  21, 0 Jan  6 23:07 /dev/sg0
crw-rw 1 root cdrom 21, 6 Jan  6 23:07 /dev/sg6
brw-rw 1 root cdrom 11, 0 Jan 17 22:28 /dev/sr0
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] useless set*id binaries

[Samuli Suominen]

On 01/28/2012 02:41 AM, Mike Frysinger wrote:

On Friday 27 January 2012 19:18:07 Samuli Suominen wrote:

On 01/28/2012 02:14 AM, Mike Frysinger wrote:

along these lines, why is cdrtools set*id ?  if we have a cdrom group,
and we assign our cdroms/dvdroms to that group, then we already have
access control in place and can skip the set*id.


cdrtools can't probe the drives without the binary being setuid, or the
user belonging to the 'disk' group (and even that is not enough in some
cases if the permissions vary)


the drives are owned by the cdrom group and have group +rw.  so if the user
is in the cdrom group, why can't they probe the drives ?

disk owns the non-removable hard drives.

$ ls -l /dev/sr0 /dev/sg0 /dev/sg6
crw-rw 1 root disk  21, 0 Jan  6 23:07 /dev/sg0
crw-rw 1 root cdrom 21, 6 Jan  6 23:07 /dev/sg6
brw-rw 1 root cdrom 11, 0 Jan 17 22:28 /dev/sr0
-mike


i dont know why, but it does probe also non-removable disks... it probes 
per bus, iirc


you can try it easily yourself:

ssuominen@null ~ $ cdrecord -scanbus
Cdrecord-ProDVD-ProBD-Clone 3.01a06 (x86_64-unknown-linux-gnu) Copyright 
(C) 1995-2011 Joerg Schilling

Linux sg driver version: 3.5.34
Using libscg version 'schily-0.9'.
scsibus0:
0,0,0 0) 'ATA ' 'WDC WD5000AADS-0' '01.0' Disk
0,1,0 1) *
0,2,0 2) *
0,3,0 3) *
0,4,0 4) *
0,5,0 5) *
0,6,0 6) *
0,7,0 7) *
scsibus1:
1,0,0   100) 'ATA ' 'ST31000333AS' 'SD25' Disk
1,1,0   101) 'TSSTcorp' 'CDDVDW SH-S223C ' 'SB06' Removable CD-ROM
1,2,0   102) *
1,3,0   103) *
1,4,0   104) *
1,5,0   105) *
1,6,0   106) *
1,7,0   107) *
scsibus4:
4,0,0   400) 'HUAWEI  ' 'Mass Storage' '2.31' Removable CD-ROM
4,1,0   401) *
4,2,0   402) *
4,3,0   403) *
4,4,0   404) *
4,5,0   405) *
4,6,0   406) *
4,7,0   407) *
scsibus5:
5,0,0   500) 'HUAWEI  ' 'TF CARD Storage ' '' Removable Disk
5,1,0   501) *
5,2,0   502) *
5,3,0   503) *
5,4,0   504) *
5,5,0   505) *
5,6,0   506) *
5,7,0   507) *
ssuominen@null ~ $ sudo chmod 755 /usr/bin/cdrecord
ssuominen@null ~ $ cdrecord -scanbus
Cdrecord-ProDVD-ProBD-Clone 3.01a06 (x86_64-unknown-linux-gnu) Copyright 
(C) 1995-2011 Joerg Schilling
cdrecord: Permission denied. Cannot open '/dev/sg0'. Cannot open or use 
SCSI driver.
cdrecord: For possible targets try 'cdrecord -scanbus'. Make sure you 
are root.

cdrecord: For possible transport specifiers try 'cdrecord dev=help'.
ssuominen@null ~ $ groups
wheel audio cdrom video games cdrw usb users portage
ssuominen@null ~ $

Re: [gentoo-dev] useless set*id binaries

[Chí-Thanh Christopher Nguyễn]

Mike Frysinger schrieb:
 along these lines, why is cdrtools set*id ?  if we have a cdrom group, and 
 we assign our cdroms/dvdroms to that group, then we already have access 
 control in place and can skip the set*id.
 -mike
From the manpage, In order to be able to use the SCSI transport
subsystem of the OS, run at highest priority and lock itself into core
cdrecord either needs to be run as root, needs to be installed suid root
or must be called via RBACs pfexec mechanism.

I guess with the advent of burnfree technology, the priority and locking
into memory have become less important.

The cdrom group will give access to /dev/sr* but not the associated /dev/sg*


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] useless set*id binaries

[Mike Frysinger]

On Friday 27 January 2012 20:07:45 Samuli Suominen wrote:
 On 01/28/2012 02:41 AM, Mike Frysinger wrote:
  On Friday 27 January 2012 19:18:07 Samuli Suominen wrote:
  On 01/28/2012 02:14 AM, Mike Frysinger wrote:
  along these lines, why is cdrtools set*id ?  if we have a cdrom
  group, and we assign our cdroms/dvdroms to that group, then we already
  have access control in place and can skip the set*id.
  
  cdrtools can't probe the drives without the binary being setuid, or the
  user belonging to the 'disk' group (and even that is not enough in some
  cases if the permissions vary)
  
  the drives are owned by the cdrom group and have group +rw.  so if the
  user is in the cdrom group, why can't they probe the drives ?
  
  disk owns the non-removable hard drives.
  
  $ ls -l /dev/sr0 /dev/sg0 /dev/sg6
  crw-rw 1 root disk  21, 0 Jan  6 23:07 /dev/sg0
  crw-rw 1 root cdrom 21, 6 Jan  6 23:07 /dev/sg6
  brw-rw 1 root cdrom 11, 0 Jan 17 22:28 /dev/sr0
  -mike
 
 i dont know why, but it does probe also non-removable disks... it probes
 per bus, iirc
 
 you can try it easily yourself:

this is a failure in cdrecord (not that surprising).  it aborts after the first 
EACCES it gets on /dev/sg# instead of continuing on.  granting set*id to a 
binary because they can't be bothered to try the next device is dumb.

$ sudo mv /dev/sg[0-5] ~/
$ sudo chmod 755 /usr/bin/cdrecord
$ cdrecord -scanbus

Cdrecord-ProDVD-ProBD-Clone 3.01a06 (x86_64-unknown-linux-gnu) Copyright (C) 
1995-2011 Joerg Schilling
TOC Type: 1 = CD-ROM
Linux sg driver version: 3.5.34
Using libscg version 'schily-0.9'.
Using libscg transport code version 'schily-scsi-linux-sg.c-1.95'
Driveropts: 'burnfree'
SCSI buffer size: 32768
scsibus7:
7,0,0   700) 'TSSTcorp' 'CDDVDW SH-S222L ' 'SB03' Removable CD-ROM
7,1,0   701) *
7,2,0   702) *
7,3,0   703) *
7,4,0   704) *
7,5,0   705) *
7,6,0   706) *
7,7,0   707) *
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] useless set*id binaries

[Samuli Suominen]

On 01/28/2012 03:49 AM, Mike Frysinger wrote:

On Friday 27 January 2012 20:07:45 Samuli Suominen wrote:

On 01/28/2012 02:41 AM, Mike Frysinger wrote:

On Friday 27 January 2012 19:18:07 Samuli Suominen wrote:

On 01/28/2012 02:14 AM, Mike Frysinger wrote:

along these lines, why is cdrtools set*id ?  if we have a cdrom
group, and we assign our cdroms/dvdroms to that group, then we already
have access control in place and can skip the set*id.


cdrtools can't probe the drives without the binary being setuid, or the
user belonging to the 'disk' group (and even that is not enough in some
cases if the permissions vary)


the drives are owned by the cdrom group and have group +rw.  so if the
user is in the cdrom group, why can't they probe the drives ?

disk owns the non-removable hard drives.

$ ls -l /dev/sr0 /dev/sg0 /dev/sg6
crw-rw 1 root disk  21, 0 Jan  6 23:07 /dev/sg0
crw-rw 1 root cdrom 21, 6 Jan  6 23:07 /dev/sg6
brw-rw 1 root cdrom 11, 0 Jan 17 22:28 /dev/sr0
-mike


i dont know why, but it does probe also non-removable disks... it probes
per bus, iirc

you can try it easily yourself:


this is a failure in cdrecord (not that surprising).  it aborts after the first
EACCES it gets on /dev/sg# instead of continuing on.  granting set*id to a
binary because they can't be bothered to try the next device is dumb.

$ sudo mv /dev/sg[0-5] ~/
$ sudo chmod 755 /usr/bin/cdrecord
$ cdrecord -scanbus

Cdrecord-ProDVD-ProBD-Clone 3.01a06 (x86_64-unknown-linux-gnu) Copyright (C)
1995-2011 Joerg Schilling
TOC Type: 1 = CD-ROM
Linux sg driver version: 3.5.34
Using libscg version 'schily-0.9'.
Using libscg transport code version 'schily-scsi-linux-sg.c-1.95'
Driveropts: 'burnfree'
SCSI buffer size: 32768
scsibus7:
 7,0,0   700) 'TSSTcorp' 'CDDVDW SH-S222L ' 'SB03' Removable CD-ROM
 7,1,0   701) *
 7,2,0   702) *
 7,3,0   703) *
 7,4,0   704) *
 7,5,0   705) *
 7,6,0   706) *
 7,7,0   707) *
-mike


and people have multiple times tried to convince the cdrtools author to 
change this, but without success.

the author can be, well, ...

i've improved the situation _a bit_:

+*cdrtools-3.01_alpha06-r1 (28 Jan 2012)
+
+  28 Jan 2012; Samuli Suominen ssuomi...@gentoo.org
+  +cdrtools-3.01_alpha06-r1.ebuild:
+  Change cdda2wav, cdrecord, readcd and rscsi from suid root to sgid 
disk for

+  udev users (note: tested with cdrecord -scanbus)

Re: [gentoo-dev] useless set*id binaries

[Mike Frysinger]

On Friday 27 January 2012 20:28:04 Chí-Thanh Christopher Nguyễn wrote:
 Mike Frysinger schrieb:
  along these lines, why is cdrtools set*id ?  if we have a cdrom group,
  and we assign our cdroms/dvdroms to that group, then we already have
  access control in place and can skip the set*id.
 
 From the manpage, In order to be able to use the SCSI transport
 subsystem of the OS, run at highest priority and lock itself into core
 cdrecord either needs to be run as root, needs to be installed suid root
 or must be called via RBACs pfexec mechanism.
 
 I guess with the advent of burnfree technology, the priority and locking
 into memory have become less important.

yeah, i would think if your system is loaded enough for this to be an issue, 
it's going to be an issue anyways.  but i'd image mlock/rtprio could be 
enabled via pam and security/limits.conf for the cdrom group.

 The cdrom group will give access to /dev/sr* but not the associated
 /dev/sg*

yes, it does:
$ find -L /dev/* -maxdepth 0 -gid 19
/dev/cdrom
/dev/cdrw
/dev/dvd
/dev/dvdrw
/dev/scd0
/dev/sg6
/dev/sr0
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] useless set*id binaries

[Mike Frysinger]

On Friday 27 January 2012 20:49:49 Samuli Suominen wrote:
 and people have multiple times tried to convince the cdrtools author to
 change this, but without success.
 the author can be, well, ...

sure, i'm not expecting him to be anything resembling reasonable.  but if we 
can reduce set*id impact by default and that means carrying a custom patch, i 
think that's OK.

i thought we used to have set*id USE flags, but maybe all the packages with it 
have migrated away.

my proposal would be to add a patch to ignore EACCES just like it already does 
for ENOENT.  then add a setuid USE flag that'd give the behavior we have today 
(disabled by default) for the binaries that do writing.  the ones that only 
read have no excuse for needing setuid.  then if the user has built with USE=-
setuid, we elog a message like:
you've built with USE=-setuid.  that means in order to access
your discs, you need to add yourself to the cdrom group.
if your burning does not go well, you can try adding the cdrom
group to limits.conf with rtprio/mlock access like so:
snippets for people to copy  paste
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] useless set*id binaries

[Ulrich Mueller]

 On Sat, 28 Jan 2012, Samuli Suominen wrote:

 i've improved the situation _a bit_:

 +*cdrtools-3.01_alpha06-r1 (28 Jan 2012)
 +
 +  28 Jan 2012; Samuli Suominen ssuomi...@gentoo.org
 +  +cdrtools-3.01_alpha06-r1.ebuild:
 +  Change cdda2wav, cdrecord, readcd and rscsi from suid root to sgid 
 disk for
 +  udev users (note: tested with cdrecord -scanbus)

This is definitely not an improvement and should be reverted. The suid
root is also needed to elevate cdrecord's scheduling priority.

And is this such an urgent matter that there wasn't time to file a
proper bug? Or have you discussed this change with the package's
maintainer?

if has_version sys-fs/udev; then
fowners root:disk /usr/bin/{cdda2wav,cdrecord,readcd} 
/usr/sbin/rscsi
fperms u-s,g+s /usr/bin/{cdda2wav,cdrecord,readcd} 
/usr/sbin/rscsi
fi

Automagic dependency on udev in src_install? Oh my.

Ulrich

Re: [gentoo-dev] useless set*id binaries

[Samuli Suominen]

On 01/28/2012 08:28 AM, Ulrich Mueller wrote:

On Sat, 28 Jan 2012, Samuli Suominen wrote:



i've improved the situation _a bit_:



+*cdrtools-3.01_alpha06-r1 (28 Jan 2012)
+
+  28 Jan 2012; Samuli Suominenssuomi...@gentoo.org
+  +cdrtools-3.01_alpha06-r1.ebuild:
+  Change cdda2wav, cdrecord, readcd and rscsi from suid root to sgid
disk for
+  udev users (note: tested with cdrecord -scanbus)


This is definitely not an improvement and should be reverted. The suid
root is also needed to elevate cdrecord's scheduling priority.


Missed that piece of code and reverted then. Any chance you could be 
more specific?



 if has_version sys-fs/udev; then
 fowners root:disk /usr/bin/{cdda2wav,cdrecord,readcd} 
/usr/sbin/rscsi
 fperms u-s,g+s /usr/bin/{cdda2wav,cdrecord,readcd} 
/usr/sbin/rscsi
 fi

Automagic dependency on udev in src_install? Oh my.


I don't consider this as a automagic to be worried about at all.
Was bouncing back and forth with 'use kernel_linux' or 'has_version 
sys-fs/udev', since wasn't sure how other devmanagers have permissions 
set. But I guess this is now irrelevant since it's reverted.