Re: /dev/acd*t* no longer available in -current?
On Fri, 15 Nov 2002, Robert Watson wrote: > So one thing we could start doing is have sysinstall's adduser stuff offer > to place new users in the operator group, and set up the default > permissions on removable devices such that the operator group has > read/write access to them (or even just read-access). This would be > logically equivilent to placing users in an admin group at instlal on > Windows or Mac OS X. Operator access connotes the ability to shut down > the system in FreeBSD, as well as the ability to dump file systems, etc. > Another possibility would be to evolve our notion of console user based on > fbtab some for workstation configurations. I've always done most of this manually. But I only normally grant write access to group operator for floppies, since my other removable devices are too large to risk clobbering them easily. (I sometimes temporarily make even non-removable disk partitions writable for testing.) Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /dev/acd*t* no longer available in -current?
Thus spake Robert Watson <[EMAIL PROTECTED]>: > So one thing we could start doing is have sysinstall's adduser stuff offer > to place new users in the operator group, and set up the default > permissions on removable devices such that the operator group has > read/write access to them (or even just read-access). This would be > logically equivilent to placing users in an admin group at instlal on > Windows or Mac OS X. Operator access connotes the ability to shut down > the system in FreeBSD, as well as the ability to dump file systems, etc. > Another possibility would be to evolve our notion of console user based on > fbtab some for workstation configurations. I think putting new users in the operator group, even as a default-off option, is more liberal than necessary. Using fbtab to allow access to removable and audio devices seems like the right thing to do. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /dev/acd*t* no longer available in -current?
On Fri, 15 Nov 2002, Sheldon Hearn wrote: > On (2002/11/15 09:48), Soeren Schmidt wrote: > > > > Don't you think it makes more sense for the kernel to start off with > > > more restrictive permissions, and have the administrator determine > > > whether more restrictive permissions are appropriate? > > > > Actually no I dont. > > The security aware admin will know (or should that be "should know" :) ) > > what to do to make a system secure. > > The avarage user that uses FreeBSD dont, and will get confused if the CDROM > > device doesn't appear to work (ie writeprotected). > > Well I think this goes against the grain of much of the work that's > happened recently. > > Look at how sysinstall now defaults to installing an inetd.conf with no > services enabled. Look at how sshd doesn't allow root login or empty > passwords by default. Look at how IPFW defaults to deny all. Look at > how the floppy drive is inaccessible to anyone but root by default. And > so on and so forth. So one thing we could start doing is have sysinstall's adduser stuff offer to place new users in the operator group, and set up the default permissions on removable devices such that the operator group has read/write access to them (or even just read-access). This would be logically equivilent to placing users in an admin group at instlal on Windows or Mac OS X. Operator access connotes the ability to shut down the system in FreeBSD, as well as the ability to dump file systems, etc. Another possibility would be to evolve our notion of console user based on fbtab some for workstation configurations. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /dev/acd*t* no longer available in -current?
On (2002/11/15 14:45), Vallo Kallaste wrote: > Yes. For what it's worth, I think that system should be airtight out > of the box and the consequences for average desktop user (as I am) > clearly documented in handbook. Users who will not read the fine > documentation fully deserve the pain. Well, in the case of being able to write to the CDRW, that's only true because sysinstall doesn't ask you whether this is a multiuser or single-user machine. One day, when sysinstall makes that distinction, it can add more permissive rules to the file that devfs(8) reads on startup if the operator indicates that the installation is for a single-user workstation. By then, I'm sure we'll be running devfs(8) on startup. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /dev/acd*t* no longer available in -current?
On Fri, Nov 15, 2002 at 04:29:50AM -0800, Kris Kennaway <[EMAIL PROTECTED]> wrote: > > > Don't you think it makes more sense for the kernel to start off with > > > more restrictive permissions, and have the administrator determine > > > whether more restrictive permissions are appropriate? > > > > Actually no I dont. > > The security aware admin will know (or should that be "should know" :) ) > > what to do to make a system secure. > > That's a particularly uncompelling argument. Yes. For what it's worth, I think that system should be airtight out of the box and the consequences for average desktop user (as I am) clearly documented in handbook. Users who will not read the fine documentation fully deserve the pain. Moreover, they probably will not make a way as fine FreeBSD user in a long run. Be sure you read the following line: IMHO -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /dev/acd*t* no longer available in -current?
On Fri, Nov 15, 2002 at 09:48:56AM +0100, Soeren Schmidt wrote: > It seems Sheldon Hearn wrote: > > On (2002/11/14 19:27), Soeren Schmidt wrote: > > > > > > - insecure permissions. Among other holes, these allowed the world to > > > > erase cd-rw's. > > > > > > Use rc.devfs for that as it was intended. > > > > Don't you think it makes more sense for the kernel to start off with > > more restrictive permissions, and have the administrator determine > > whether more restrictive permissions are appropriate? > > Actually no I dont. > The security aware admin will know (or should that be "should know" :) ) > what to do to make a system secure. That's a particularly uncompelling argument. Kris msg46713/pgp0.pgp Description: PGP signature
Re: /dev/acd*t* no longer available in -current?
On Fri, 15 Nov 2002, Sheldon Hearn wrote: > On (2002/11/15 09:48), Soeren Schmidt wrote: > > > > Don't you think it makes more sense for the kernel to start off with > > > more restrictive permissions, and have the administrator determine > > > whether more restrictive permissions are appropriate? > > > > Actually no I dont. > > The security aware admin will know (or should that be "should know" :) ) > > what to do to make a system secure. > > The avarage user that uses FreeBSD dont, and will get confused if the CDROM > > device doesn't appear to work (ie writeprotected). > > Well I think this goes against the grain of much of the work that's > happened recently. It is just a bug. SCSI cd devices never had this bug, and acd devices don't have it in the non-devfs case. Average users don't depend on this bug since average users run RELENG_4 which doesn't have devfs. Some other devices have even more insecure permissions. Sound devices have mode 0666. This bugs is "documented" in the snd_security_hole variable name in MAKEDEV. For devfs, you can grep the kernel sources for 0666 to find similar security holes. There are an alarming number of 0666's. Most are for ptys where they are OK. The most obviously wrong ones are for rp. rp devices have mode 0666 in the devfs case. rp gets this wrong in the opposite direction in MAKEDEV -- it is missing a "umask 7" for the cua case, so its cua devices are not group readable. rp also gets the user and group wrong for the cua devices the devfs case, so world r/w permissions are necessary to grant even the usual access to uucp:dialer. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /dev/acd*t* no longer available in -current?
On Thu, 14 Nov 2002, Soeren Schmidt wrote: > It seems Bruce Evans wrote: > > Single-digit track numbers are correct and are still generated by MAKEDEV. > > Single digit track numbers are wrong and should be fixed in MAKEDEV. I disagree. > > Contrary to the log message, %02d is harder for scripts. It gives many > > more cases to handle: > > - %d format under RELENG_4 > > Should be fixed. Apart from being wrong, this would break compatibility with released versions of RELENG_4 (except 4.0-4.2 since they didn't support tracks on acd). > > - %d format under -current in the non-devfs case > > DEVFS should be considered mandatory for the track devices on current. No thanks. I only use devfs to debug it. > > - %d format under -current even in the devfs case for track numbers >= 100 > > BZZT!! there can be a max of 99 tracks on a CD. Thnaks for your polite correction. I was misled by MAKEDEV supporting track numbers up to 169. Google agrees that the maximum is 99, but cd drivers in linux-2.4.1 have an interesting number of different definitions of the maximum: aztcd.h:#define MAX_TRACKS 104 cdu31a.h:#define MAX_TRACKS 100 /* The maximum tracks a disk may have. */ gscd.h:#define MAX_TRACKS 104 mcd.h:#define MAX_TRACKS104 optcd.c:#define MAX_TRACKS 111 sbpcd.h:#define MAX_TRACKS 99 sjcd.h:#define SJCD_MAX_TRACKS 100 > > The following patch backs out rev.1.119 of atapi-cd.c and fixes the > > following older devfs bugs in acd: > > - insecure permissions. Among other holes, these allowed the world to > > erase cd-rw's. > > Use rc.devfs for that as it was intended. rc.devfs is not intended for fixing kernel bugs. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /dev/acd*t* no longer available in -current?
On (2002/11/15 09:48), Soeren Schmidt wrote: > > Don't you think it makes more sense for the kernel to start off with > > more restrictive permissions, and have the administrator determine > > whether more restrictive permissions are appropriate? > > Actually no I dont. > The security aware admin will know (or should that be "should know" :) ) > what to do to make a system secure. > The avarage user that uses FreeBSD dont, and will get confused if the CDROM > device doesn't appear to work (ie writeprotected). Well I think this goes against the grain of much of the work that's happened recently. Look at how sysinstall now defaults to installing an inetd.conf with no services enabled. Look at how sshd doesn't allow root login or empty passwords by default. Look at how IPFW defaults to deny all. Look at how the floppy drive is inaccessible to anyone but root by default. And so on and so forth. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /dev/acd*t* no longer available in -current?
It seems Sheldon Hearn wrote: > On (2002/11/14 19:27), Soeren Schmidt wrote: > > > > - insecure permissions. Among other holes, these allowed the world to > > > erase cd-rw's. > > > > Use rc.devfs for that as it was intended. > > Don't you think it makes more sense for the kernel to start off with > more restrictive permissions, and have the administrator determine > whether more restrictive permissions are appropriate? Actually no I dont. The security aware admin will know (or should that be "should know" :) ) what to do to make a system secure. The avarage user that uses FreeBSD dont, and will get confused if the CDROM device doesn't appear to work (ie writeprotected). -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /dev/acd*t* no longer available in -current?
On (2002/11/14 19:27), Soeren Schmidt wrote: > > - insecure permissions. Among other holes, these allowed the world to > > erase cd-rw's. > > Use rc.devfs for that as it was intended. Don't you think it makes more sense for the kernel to start off with more restrictive permissions, and have the administrator determine whether more restrictive permissions are appropriate? I think this approach is much more in line with "the Unix way". Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /dev/acd*t* no longer available in -current?
It seems Bruce Evans wrote: > Single-digit track numbers are correct and are still generated by MAKEDEV. Single digit track numbers are wrong and should be fixed in MAKEDEV. > The devfs numbers were broken in: > > % RCS file: /home/ncvs/src/sys/dev/ata/atapi-cd.c,v > % Working file: atapi-cd.c > % head: 1.126 > % ... > % > % revision 1.119 > % date: 2002/05/28 17:39:17; author: sos; state: Exp; lines: +1 -1 > % Use %02d in track numbers, so that 1 is 01, much easier for scripts > % > > Contrary to the log message, %02d is harder for scripts. It gives many > more cases to handle: > - %d format under RELENG_4 Should be fixed. > - %d format under -current in the non-devfs case DEVFS should be considered mandatory for the track devices on current. > - %d format under -current even in the devfs case for track numbers >= 100 BZZT!! there can be a max of 99 tracks on a CD. > - %02d under -current in the devfs case for track numbers < 100. Thats actually the one thats right :) > The following patch backs out rev.1.119 of atapi-cd.c and fixes the > following older devfs bugs in acd: > - insecure permissions. Among other holes, these allowed the world to > erase cd-rw's. Use rc.devfs for that as it was intended. > - hard-coded ownerships leading to broken groups for the track devices. Well, that sounds like a bug alright... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /dev/acd*t* no longer available in -current?
On Wed, 13 Nov 2002, Conrad Sabatier wrote: > Please disregard. I discovered it was just that I was using single-digit > track numbers (e.g., acd0t1), whereas leading-zero numbers were expected > (e.g., acd0t01). > > Sorry 'bout that. :\ > > On 13-Nov-2002 Conrad Sabatier wrote: > > I've been using a homemade CD ripping script under -stable that uses dd > > with the acd0t* devices. Unfortunately, these seem no longer to exist in > > -current, or am I mistaken? > > > > I'm still a bit perplexed by devfs, to be honest. Is there any way to > > create these devices (if they are still supported, that is)? Single-digit track numbers are correct and are still generated by MAKEDEV. The devfs numbers were broken in: % RCS file: /home/ncvs/src/sys/dev/ata/atapi-cd.c,v % Working file: atapi-cd.c % head: 1.126 % ... % % revision 1.119 % date: 2002/05/28 17:39:17; author: sos; state: Exp; lines: +1 -1 % Use %02d in track numbers, so that 1 is 01, much easier for scripts % Contrary to the log message, %02d is harder for scripts. It gives many more cases to handle: - %d format under RELENG_4 - %d format under -current in the non-devfs case - %d format under -current even in the devfs case for track numbers >= 100 - %02d under -current in the devfs case for track numbers < 100. The following patch backs out rev.1.119 of atapi-cd.c and fixes the following older devfs bugs in acd: - insecure permissions. Among other holes, these allowed the world to erase cd-rw's. - hard-coded ownerships leading to broken groups for the track devices. %%% Index: atapi-cd.c === RCS file: /home/ncvs/src/sys/dev/ata/atapi-cd.c,v retrieving revision 1.126 diff -u -2 -r1.126 atapi-cd.c --- atapi-cd.c 18 Oct 2002 22:03:34 - 1.126 +++ atapi-cd.c 14 Nov 2002 13:10:52 - @@ -282,5 +282,5 @@ dev = make_dev(&acd_cdevsw, dkmakeminor(cdp->lun, 0, 0), - UID_ROOT, GID_OPERATOR, 0644, "acd%d", cdp->lun); + UID_ROOT, GID_OPERATOR, 0640, "acd%d", cdp->lun); make_dev_alias(dev, "acd%da", cdp->lun); make_dev_alias(dev, "acd%dc", cdp->lun); @@ -1330,8 +1330,8 @@ char name[16]; - sprintf(name, "acd%dt%02d", cdp->lun, track); + sprintf(name, "acd%dt%d", cdp->lun, track); entry = malloc(sizeof(struct acd_devlist), M_ACD, M_NOWAIT | M_ZERO); entry->dev = make_dev(&acd_cdevsw, (cdp->lun << 3) | (track << 16), - 0, 0, 0644, name, NULL); + UID_ROOT, GID_OPERATOR, 0640, name, NULL); entry->dev->si_drv1 = cdp->dev->si_drv1; TAILQ_INSERT_TAIL(&cdp->dev_list, entry, chain); %%% Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /dev/acd*t* no longer available in -current?
Please disregard. I discovered it was just that I was using single-digit track numbers (e.g., acd0t1), whereas leading-zero numbers were expected (e.g., acd0t01). Sorry 'bout that. :\ On 13-Nov-2002 Conrad Sabatier wrote: > I've been using a homemade CD ripping script under -stable that uses dd > with the acd0t* devices. Unfortunately, these seem no longer to exist in > -current, or am I mistaken? > > I'm still a bit perplexed by devfs, to be honest. Is there any way to > create these devices (if they are still supported, that is)? > > Any info/help much appreciated. > > -- > Conrad Sabatier <[EMAIL PROTECTED]> > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-multimedia" in the body of the message > -- Conrad Sabatier <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
/dev/acd*t* no longer available in -current?
I've been using a homemade CD ripping script under -stable that uses dd with the acd0t* devices. Unfortunately, these seem no longer to exist in -current, or am I mistaken? I'm still a bit perplexed by devfs, to be honest. Is there any way to create these devices (if they are still supported, that is)? Any info/help much appreciated. -- Conrad Sabatier <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
