Combining Entries in devfs.conf

U

usakhncit

Hi
We have entries in /etc/devfs.conf like:
Code: 
perm    /dev/da0        666
perm    /dev/da1        666
perm    /dev/da2        666
perm    /dev/da3        666
so, can we write these entries in following manner?
Code: 
perm    /dev/da[0-3]    666
Thanks
 
SirDice said:
It's a bad idea to make those devices world-writable in the first place.
Click to expand...
1. I imported them (to my FreeBSD) by taking inspiration from GhostBSD, so it means that GhostBSD is doing wrong here!
2. What's your opinion about combining the entries? Is it good or bad?
 
devfs.conf doesn't support glob patterns, devfs.rules does. Reading the manpages, I still don't know for sure whether you can do that kind of configuration in a rules-file. For devices available at boot time, you're refered to devfs.conf.

As for GhostBSD doing it wrong: certainly. I don't see any good reason to allow any user to access these devices, circumventing the file system.

edit: maybe I was too quick here. If da* devices are only removable media, it might make sense. But then, this should probably be done in devfs.rules as they are typically not available at boot time anyways. There you can do something like
Code: 
add path 'da[0-9]\*'    mode 666
 
Zirias said:
If da* devices are only removable media, it might make sense.
Click to expand...
Still should only allow group writes 660 (operator for example) and the user added to the operator group. Allowing everything but the kitchen-sink unfettered write access to a disk device seems like a recipe for disaster.
 
SirDice said:
Still should only allow group writes 660 (operator for example) and the user added to the operator group. Allowing everything but the kitchen-sink unfettered write access to a disk device seems like a recipe for disaster.
Click to expand...
Well, IF only removable media is affected and IF all users of this (presumably) desktop box should be granted unlimited access, the only difference would be the "hole" this opens up for system accounts (daemons on that box). I agree, handling this with a group is certainly the better option (have seen Linux distributions that established a "plugdev" group for that). I wonder why GhostBSD doesn't follow that route…
 
This may not be the proper forum but I wonder that why GhostBSD chose (666) for permissions! " Its developer (ericbsd) is clever enough to not do that. Maybe he has his reasons.
 
You must log in or register to reply here.
Back
Top