|
|
|
|
|
|
| Author |
Message |
Andrew Reilly
*nix forums Guru Wannabe
Joined: 26 Apr 2002
Posts: 148
|
 Posted: Mon Jun 26, 2006 11:58 pm Post subject:
OT: Re: Accessing disks via their serial numbers.
|
|
|
On Mon, Jun 26, 2006 at 03:55:22PM +0000, Poul-Henning Kamp wrote:
| Quote: | The reason people have trouble understanding this very basic point is
that UCB strayed from the UNIX philosophy when they added all the socket
system calls instead of adding the /net filesystem.
|
I don't know if anyone's interested, but I started to have a
look at Minix-3 the other day. Andrew Tanenbaum is trying to
make it grow into a real, useful embedded OS, so now it has a
"TCP/IP" network stack (and fully scheduled user-mode device
drivers...) The interesting thing is that the TCP/IP stack
doesn't provide sockets. It provides /dev/rtk (etc) for raw
ethernet drivers, and /dev/ip for raw IP and /dev/tcp for TCP
sessions. You open /dev/tcp, do ioctl's to make a connection
and then read()/write() to send and receive data.
Totally off topic, but kind of interesting, too...
Cheers,
--
Andrew
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
 |
Jia-Shiun Li
*nix forums beginner
Joined: 27 Jun 2006
Posts: 1
|
| Posted: Tue Jun 27, 2006 6:26 am Post subject:
Re: Accessing disks via their serial numbers.
|
|
|
On 6/27/06, Paul Schenkeveld <fb-arch@psconsult.nl> wrote:
| Quote: | These arguments are the reason I started out to state that I don't want
to "change the way the world is and certainly not violate POLA" but
the issue is one I have been thinking about for many years. The way
we identify multiple instances of the same type of device in UN*X like
systems will always have drawbacks, whichever scheme we choose.
Currently, with multiple controllers using the same driver there is
always the randomness of which gets detected first by the kernel. If,
for example, you have two SCSI controllers, an AHA2940 and an AHA29160,
then have to replace one by a newer model which uses the same driver,
the numbering may reverse or replacing the first one by a controller
which uses a different driver shifts the number of the second controller
down by 1.
Back in the old days the AT&T 3B had a nice bus with address space
divided in ranges per slot so the system always knew in which slot a
card was but adding an extra card sometimes meant you had to move an
existing card if for example cables and connectors would otherwise
become unreachable.
Another interesting challenge is the miriad of devices that come and go
over time like USB and firewire attached drives, flash cards that slip
into the side of a notebook etc.
Using a serial number on the device as the OP suggests works until
you have to replace broken hardware. And some hardware may not have
readable serial numbers at all like flash memory devices.
With soft labels stored on a disk the sysadmin at least can control
behaviour to some extent but there are certainly corner cases where
labels are inconvenient.
So having a choice between several different schemes is perhaps the best
way to keep many sysadmins happy.
As far as I know, for ATA the problem is solved with ATA_STATIC_ID,
and IMO it is solved better that way.
This then begs the question if we should instead introduce a generic
DISK_STATIC_ID which all controllers respect ?
ATA_STATIC_ID certainly keeps frustration away in many cases and having
all drivers behave the same way and change to DISK_STATIC_ID is probably
even much better.
For CAM disks I guess this would mean encoding all of (bus,id,lun)
in the device name:
/dev/da0:0:1
or some such.
Like /dev/[r]dsk/c0b0t0d0l0s1a as in SysV ;-(
Yes this could be handy in some situations where the sysadmin has
everything to say about SCSI IDs and LUNs but as I said before,
whichever way we choose will solve the problem for some and create a
problem for others.
Having a choice is good, especially if one can choose which scheme to
use by including GEOMs in the kernel or loading them at boot time. The
current default of ad*, da* and so on could (IMO should) stay and remain
the default to not violate POLA.
|
That's pretty what I think of too. Imagine situation like this that
someone has two fxp adapter configured on system. Plugging another one
will certainly cause some troubles as he now has problem identify
which is fxp0, fxp1, or fxp2. Not all users know how the system probes
and enumerate hardware, even if he knows, he still has trouble knowing
how hardware are probed on 'his' system as motherboard layouts are
different from one to another. Not to mention various versions of
i8255[78901] under the same fxp name with different hardware
capabilities. The same stands for storages adapters and worse because
they have disks as children.
Having everything work under the big device tree may be a good
solution for unique addressing from programmers' point of view. But
'unique' also means sometimes you have to find out where it is. Serial
numbers are unique to the users, and hierarchy names are unique to the
system (and admin). There are differences.
Take some other examples. If one pull out network adapter and plug it
into another slot, in Windows he will get a new "Local Connection 5"
and have to re-configure its IP setting. Fortunately the default DHCP
works for me in most cases btw. That means Windows use adapter AND
slot positions to uniquely identify a network connection for user.
AFAIK Fedora uses similar scheme to identify hardwares and keep it in
configuration files so kudzu will know when new hardware appears.
I guess pjd initially wanted to solve problems like roaming USB disks
or get rid of ATA_STATIC_ID. It would be better if you can describe
the problems to solve in detail.
Because of the nature we need to bind data to specific hardware, for
example IP address, mounting points, or files on disks, it is good to
have a solution to achieve it instead of depending on the may-change
device numbers. Serial number is a good starting point, but it does
not necessarily need to go into /dev as many people mentioned all the
concerns.
One possible solution: providing that uses can get serial number to
device node mapping in user space, it could be easy to implement a
mechanism, for example in shell scripts, for those who need it. Any
comment?
In my opinion I have to say, I do not feel it is a good idea to mix
the concept of serial numbers and various device attributes with the
device names or internal hierarchical representation. They can be
coupled but it is probably too closely related if implemented in
device tree.
Jia-Shiun.
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Peter Jeremy
*nix forums addict
Joined: 13 Jun 2002
Posts: 77
|
| Posted: Tue Jun 27, 2006 8:03 am Post subject:
Re: Accessing disks via their serial numbers.
|
|
|
On Mon, 2006-Jun-26 18:46:19 +0000, Poul-Henning Kamp wrote:
| Quote: | 4. It prevents cold-state swapout of disk drives.
Why?
Because /etc/fstab contains the serial number of the disk you just
junked and the new one has a different serial number.
|
I've used a couple of OSs that derived their logical disk name (ie
/dev/disk/dsk5) from the WWID by keeping a magic database to map
the WWID to the name. None of them have good solutions to telling
the OS that WWID-x has died and I want WWID-y to now map to the same
logical device as WWID-x used to.
Actually having the WWID (or similar) as the logical name would make
handling a disk swap really nasty.
Stating that the sysadmin knows about the change doesn't address the
issue: The sysadmin changed the device because the old one failed.
There may or may not have been advance notice of the replacement.
--
Peter Jeremy |
|
| Back to top |
|
|
Peter Jeremy
*nix forums addict
Joined: 13 Jun 2002
Posts: 77
|
| Posted: Tue Jun 27, 2006 9:36 am Post subject:
Re: OT: Re: Accessing disks via their serial numbers.
|
|
|
On Tue, 2006-Jun-27 09:58:45 +1000, Andrew Reilly wrote:
| Quote: | I don't know if anyone's interested, but I started to have a
look at Minix-3 the other day. ...
You open /dev/tcp, do ioctl's to make a connection
and then read()/write() to send and receive data.
|
That sounds similar to the SysV approach - you open a device
and push a collection of streams modules.
I'm not sure that ioctl() is any better than bind/connect etc -
a process still needs special code if it's to be network-aware.
IMHO, the portal filesystem provides a far more interesting
approach.
--
Peter Jeremy |
|
| Back to top |
|
|
Pawel Jakub Dawidek
*nix forums addict
Joined: 24 Jun 2003
Posts: 92
|
| Posted: Tue Jun 27, 2006 11:21 am Post subject:
Re: Accessing disks via their serial numbers.
|
|
|
On Tue, Jun 27, 2006 at 06:03:12PM +1000, Peter Jeremy wrote:
| Quote: | On Mon, 2006-Jun-26 18:46:19 +0000, Poul-Henning Kamp wrote:
4. It prevents cold-state swapout of disk drives.
Why?
Because /etc/fstab contains the serial number of the disk you just
junked and the new one has a different serial number.
I've used a couple of OSs that derived their logical disk name (ie
/dev/disk/dsk5) from the WWID by keeping a magic database to map
the WWID to the name. None of them have good solutions to telling
the OS that WWID-x has died and I want WWID-y to now map to the same
logical device as WWID-x used to.
Actually having the WWID (or similar) as the logical name would make
handling a disk swap really nasty.
Stating that the sysadmin knows about the change doesn't address the
issue: The sysadmin changed the device because the old one failed.
There may or may not have been advance notice of the replacement.
|
I'm not saying it solves all problems, but it is very useful in certain
situations, where what you mentioned is not the case.
For software RAID you still has to somehow say that this driver replaced
that one.
--
Pawel Jakub Dawidek http://www.wheel.pl
pjd@FreeBSD.org http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am! |
|
| Back to top |
|
|
Sergey Babkin
*nix forums beginner
Joined: 15 Jul 2004
Posts: 24
|
| Posted: Tue Jun 27, 2006 11:34 am Post subject:
Re: Re: Accessing disks via their serial numbers.
|
|
|
| Quote: | From: Peter Jeremy <peterjeremy@optushome.com.au
On Mon, 2006-Jun-26 18:46:19 +0000, Poul-Henning Kamp wrote:
4. It prevents cold-state swapout of disk drives.
Why?
Because /etc/fstab contains the serial number of the disk you just
junked and the new one has a different serial number.
I've used a couple of OSs that derived their logical disk name (ie
/dev/disk/dsk5) from the WWID by keeping a magic database to map
the WWID to the name. None of them have good solutions to telling
the OS that WWID-x has died and I want WWID-y to now map to the same
logical device as WWID-x used to.
|
I can tell about my experience with this kind of thing in
UnixWare. AFAIK the primary motivation for tracking the
disks by serial numbers was the Multi-Path I/O: having the
same disk accessible through two controllers, so that if
one access path fails, the OS can switch transparently
to another path. (Well, in reality such a disk would
probably be not just a disk but a logical volume in a
RAID box with 2 redundant controllers in it, each connected
to the host through a separate SCSI of FibreChannel bus).
To do this you need ways to discover that both paths
lead to the same disk. UnixWare does this by writing
a randomly generated unique ID into the UnixWare partition.
When the disks are enumerated, the partition (VTOC)
code reads this ID and checks it against the database
of known IDs in the resource manager. When a match
is found, the disk gets connected to an existing
logical name. As the resource manager database gets
saved between reboots, this also gives you the persistence
of disk names between reboots.
As a good side effect it allowed to move disks around
in every which way between the slots and connections
while keeping the same logical name.
As a bad side effect, you would never know what some
logical name refers to until you check the mapping table.
Worse yet, since the logical names have been kept of
the same format as the physical names (cNbNtNdN), if you
happen to have a disk in c1b1t1d1 and then move it to
another slot, it keeps the name, and when you put another
disk into the original slot, you don't see it at all
(I think, unless I forget something) until you reset the
mappings or unplug the original disk - then the name
magically transfers to the new disk. And since the
mappings persist, they tend to accumulate if you swap
the disks often. It's not really an issue with the
concept itself, its' just tha the logical names should
have a different format than the physical ones to
avoid confusion.
The mapping-controlling tools are kind of poor too but
again this is solely the issue with the tools, not with
the concept. If you are creative with direct manipulation
of the resource manager entries, you can do many
things that the tools won't allow you. The resource
manager manipulation tools are kind of poor in UnixWare
too but again it's not an issue with the concept itself.
| Quote: | Actually having the WWID (or similar) as the logical name would make
handling a disk swap really nasty.
|
That's not a problem in UnixWare. If the original disk
has gone away completely, the new disk in the same SCSI slot
would just get the same logical name.
Things get more interesting for USB: to do the Right Thing
sometimes it would be neccessary to attach the same
name to any device (of the same type) in the same slot,
and sometimes to the same device in any slot.
| Quote: | Stating that the sysadmin knows about the change doesn't address the
issue: The sysadmin changed the device because the old one failed.
There may or may not have been advance notice of the replacement.
|
There should just be a way for sysadmin to communicate this
knowledge to the system. For an UnixWare example again,
it has a command saying "I'm about to hot swap this disk,
do whatever is neccessary to stop the old disk, and then
start and recognize the new one". Of course, in any
seriour datacenter the swap would happen inside a RAID
box and the OS won't see it at all.
-SB
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
M. Warner Losh
*nix forums Guru
Joined: 22 Mar 2002
Posts: 365
|
| Posted: Tue Jun 27, 2006 4:33 pm Post subject:
Re: Accessing disks via their serial numbers.
|
|
|
In message: <52322.1151337322@critter.freebsd.dk>
"Poul-Henning Kamp" <phk@phk.freebsd.dk> writes:
: In message <20060626.093240.-432837692.imp@bsdimp.com>, "M. Warner Losh" writes
: :
:
: >: I suspect that the proponents of this scheme will object to my proposal
: >: because they can not do a "ls /dev/mumble/*" to get a list of disk
: >: serial numbers[...]
: >
: >I'm curious... what's wrong with adding additional things to the /dev
: >directory? One of the biggest annoyances I have in troubleshooting is
: >not being able to see what files are there and having magic file names
: >that one can open but not list.
:
: devfs is not a hardware inventory facility, it is magic place for
: performing a rendez-vous with a device driver.
True, but somewhat irrelvant. This does not go to the question that I
asked. What problems does having fully enumerated devices cause?
devfs does allow directory listings, therefore absent some compelling
reason to the contrary these listings should be complete. This is an
enumeration of the available devices, which closely mirrors the
available hardware. There are other facilities for finding out the
underlying hardware, but there's no way to find the magic names in
/dev easily. While it is a magic place, that magic place exists in
the context of a file system, and file systems aren't supposed to
randomly open files.
It is also a security concern. If I wanted to have non-default
permissions on these magic nodes, at the very least I'd have no way to
audit them. I'm unclear if doing the normal unix operations on the
magic nodes would suffice.
: We really do not want to prepopulate /dev with all possible devices,
: that model broke down in the late 1980ies and it has not become more
: feasible in the meantime.
You are arguing apples and oranges here. The fully enumerated /dev
with all possible device entries based on what the machine might
possibly have is not what I'm asking. We all know there are issues
with that. My question is more specific. What is wrong with having
entries in devfs of files you can actually open, when we know the
universe that is possible given the current knowledge of the kernel?
Why have some of them hidden and some of them present? Why subject
the user to the hassles that having hidden, magic files causes?
: The reason people have trouble understanding this very basic point is
: that UCB strayed from the UNIX philosophy when they added all the socket
: system calls instead of adding the /net filesystem.
Again, you are comparing apples to oranges. The current local node
cannot know the list of possibilities for nodes on the network. In
the specific case that I'm asking about, we do know the possibilities.
The number of entries, even on a large system, is relatively small.
: If we had /net, everybody would be able to see that non-storage filesystems
: should not be prepopulated with every conceiveable vnode.
This is true, but irrelevant. There are different design
considerations for different types of virtual file systmes.
: The automounter is another good example: here quite complex software
: was written specifically to avoid prepopulation with all conceiveable
: vnodes and mountpoints, that that is even for storage filesystems.
This is a bug in the automounter, and has been for a very long time.
I've always hated it.
My big problem with magic files and hiding them is that it becomes
difficult or impossible to diagnose and troubleshoot. They can create
security problems, especially if there's no way to audit their
existance and attributes. If there's a real, compelling reason to
hide the files, I might understand. But so far I've seen no real,
compelling reason proffered as to why the kernel can't expose the
knowledge that it has in this manner.
Warner
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Poul-Henning Kamp
*nix forums Guru
Joined: 21 Mar 2002
Posts: 436
|
| Posted: Tue Jun 27, 2006 4:53 pm Post subject:
Re: Accessing disks via their serial numbers.
|
|
|
In message <20060627.103343.-432837786.imp@bsdimp.com>, "M. Warner Losh" writes
:
| Quote: | : devfs is not a hardware inventory facility, it is magic place for
: performing a rendez-vous with a device driver.
True, but somewhat irrelvant.
|
Not really, it has to be kept in mind to avoid decending into the
hell currently reserved for Linux procfs :-)
| Quote: | True, but somewhat irrelvant. This does not go to the question that I
asked. What problems does having fully enumerated devices cause?
|
There is no problem with fully enumerated devices, as long as
they don't cause an explosion in the number of devices.
| Quote: | devfs does allow directory listings, therefore absent some compelling
reason to the contrary these listings should be complete. This is an
enumeration of the available devices, which closely mirrors the
available hardware.
|
The problem is that it exactly doesn't do that, and can't possibly
do that, because hardware is not seen by devfs until the driver
is loaded.
I realize that this sounds a bit Clintonesque, but it all comes
down to what your definition of "available" is.
For instance, the crypt-hw support has one joint device node in /dev
but can cover up 16 cards, without ever disclosing to you what
they are or what they can do, until you open the joint device and
ask with the right ioctls.
| Quote: | There are other facilities for finding out the
underlying hardware, but there's no way to find the magic names in
/dev easily.
|
Only whatever convention we decide to use to pick the names them
can help you there.
| Quote: | While it is a magic place, that magic place exists in
the context of a file system, and file systems aren't supposed to
randomly open files.
|
You lost me there...
| Quote: | It is also a security concern. If I wanted to have non-default
permissions on these magic nodes, at the very least I'd have no way to
audit them. I'm unclear if doing the normal unix operations on the
magic nodes would suffice.
|
We have the devfs( rules for that.
| Quote: | My question is more specific. What is wrong with having
entries in devfs of files you can actually open, when we know the
universe that is possible given the current knowledge of the kernel?
|
We generally have that.
The only exceptions I'm aware of right now are pseudo devices, for
which precreation doesn't make sense at all.
| Quote: | My big problem with magic files and hiding them is that it becomes
difficult or impossible to diagnose and troubleshoot.
|
I have a very big problem with magic files as well.
Currently g_label doesn't impose any restrictions on the label
strings of the device, which means that you can include '/', '..'
and ';' in labels. I don't need to tell you what that means
for shell scripts etc. Put a g_label on an USB key and trick
the admin into to doing something stupid and you're all set:
just type
mount -t msdos /dev/da0*
I can't remember which slice it is...
The reason why I am advocating using "on-demand" names for
what Pawel is proposing is that way the names only exist
if people ask for them, and only the names they ask for exists.
In addition to avoiding a wanton doubling of the geom mesh
size (because he does it at the very bottom) that also
adds significant flexibilty and security to the table.
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
M. Warner Losh
*nix forums Guru
Joined: 22 Mar 2002
Posts: 365
|
| Posted: Tue Jun 27, 2006 6:04 pm Post subject:
Re: Accessing disks via their serial numbers.
|
|
|
In message: <62122.1151427182@critter.freebsd.dk>
"Poul-Henning Kamp" <phk@phk.freebsd.dk> writes:
: >True, but somewhat irrelvant. This does not go to the question that I
: >asked. What problems does having fully enumerated devices cause?
:
: There is no problem with fully enumerated devices, as long as
: they don't cause an explosion in the number of devices.
That's my view as well! We agree!
: >devfs does allow directory listings, therefore absent some compelling
: >reason to the contrary these listings should be complete. This is an
: >enumeration of the available devices, which closely mirrors the
: >available hardware.
:
: The problem is that it exactly doesn't do that, and can't possibly
: do that, because hardware is not seen by devfs until the driver
: is loaded.
:
: I realize that this sounds a bit Clintonesque, but it all comes
: down to what your definition of "available" is.
:
: For instance, the crypt-hw support has one joint device node in /dev
: but can cover up 16 cards, without ever disclosing to you what
: they are or what they can do, until you open the joint device and
: ask with the right ioctls.
Don't be silly here. I'm arguing that available be defined as those
devices that are physically persent in the system, and have their
device driver loaded for them. Twisting "available" in that
Clintonesque way isn't what I'm talking about. I'm talking about
plain, ordinary meaning of available here: those things the kernel has
direct knowledge of.
: >While it is a magic place, that magic place exists in
: >the context of a file system, and file systems aren't supposed to
: >randomly open files.
:
: You lost me there...
Filesystems generally give the ability to enumerate names at a given
level of the file system (ls /usr should be no different than ls
/dev), plus the ability to open files that appear in ls listings.
magic filenames make an end run around this by being able to open
files that you cannot list. Listing here includes discoving meta data
such as ownership, permissions, acls, etc.
[[ I'm ignoring the 'x' bit semantics, because sufficiently
privileged users can override that. With magic files there's
no such privilege that can override that. ]]
: >It is also a security concern. If I wanted to have non-default
: >permissions on these magic nodes, at the very least I'd have no way to
: >audit them. I'm unclear if doing the normal unix operations on the
: >magic nodes would suffice.
:
: We have the devfs( rules for that.
And no way to audit them. The basic problem that I'd have in this
specific case (serial numbers ala some variation of /dev/ad/ABCDEFG)
is that the system administrator cannot set and verify the permissions
of the filename. If there's a typo in devfs with 'normal' devices,
then a simple ls will show that something is wrong. With magic
devices that don't appear in ls, there's no way to know if it was
created correctly, or if something went wrong.
: >My question is more specific. What is wrong with having
: >entries in devfs of files you can actually open, when we know the
: >universe that is possible given the current knowledge of the kernel?
:
: We generally have that.
:
: The only exceptions I'm aware of right now are pseudo devices, for
: which precreation doesn't make sense at all.
Yes. Those make sense. Since we create ptys, for example, on demand,
having only those ptys that are in the system right now makes good
sense.
: >My big problem with magic files and hiding them is that it becomes
: >difficult or impossible to diagnose and troubleshoot.
:
: I have a very big problem with magic files as well.
:
: Currently g_label doesn't impose any restrictions on the label
: strings of the device, which means that you can include '/', '..'
: and ';' in labels. I don't need to tell you what that means
: for shell scripts etc. Put a g_label on an USB key and trick
: the admin into to doing something stupid and you're all set:
:
: just type
: mount -t msdos /dev/da0*
: I can't remember which slice it is...
A simple fix to this would be to have a sysctl that says to filter or
allow magic characters in the label name.
Shell characters like ';' aren't expanded into the shell command, so
if there were '; sh' in the label, the above command wouldn't be
affected by it. No root shell would be created. I'll concede that
one can construct scenarios where this does present a problem, but
they are difficult.
The command would have to be something more like:
mount -t msdos /dev/da0s? /dos
to avoid false positives, and even then it fails with disks that have
multiple slices.
: The reason why I am advocating using "on-demand" names for
: what Pawel is proposing is that way the names only exist
: if people ask for them, and only the names they ask for exists.
Making them on-demand makes it impossible to audit. Right now, if I'm
owrried abotu disk security, I can do:
% ls -l /dev/ad*
crw-r----- 1 root operator 0, 61 Jun 27 10:19 /dev//ad0
crw-r----- 1 root operator 0, 62 Jun 27 10:19 /dev/ad0s1
crw-r----- 1 root operator 0, 63 Jun 27 10:19 /dev/ad0s2
crw-r----- 1 root operator 0, 64 Jun 27 10:19 /dev/ad0s3
crw-r----- 1 root operator 0, 65 Jun 27 10:19 /dev/ad0s4
crw-r----- 1 root operator 0, 66 Jun 27 04:19 /dev/ad0s4a
crw-r----- 1 root operator 0, 67 Jun 27 10:19 /dev/ad0s4b
crw-r----- 1 root operator 0, 68 Jun 27 10:19 /dev/ad0s4c
crw-r----- 1 root operator 0, 69 Jun 27 04:19 /dev/ad0s4d
crw-r----- 1 root operator 0, 70 Jun 27 04:19 /dev/ad0s4e
crw-r----- 1 root operator 0, 71 Jun 27 04:19 /dev/ad0s4f
crw-r----- 1 root operator 0, 72 Jun 27 04:19 /dev/ad0s4g
As can clearly be shown, absent any unknown security bugs, only root
can write to these devices, while those in group operator can read.
A better way to control their creation is by either the presence or
absense of the module, or by a sysctl in the module to control their
creation.
: In addition to avoiding a wanton doubling of the geom mesh
: size (because he does it at the very bottom) that also
: adds significant flexibilty and security to the table.
I understand the doubling argument. This can be a good argument if
the number of entries is very large (I've not seen even large systems
have more than 100 entries, and if this is off by default, then
there's no damage). However, I'm not sure I understand the
flexibility and security side of things. Properly written and
implemented, I'm not sure how it affects security.
Warner
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Sergey Babkin
*nix forums beginner
Joined: 15 Jul 2004
Posts: 24
|
| Posted: Tue Jun 27, 2006 6:22 pm Post subject:
Re: Re: Accessing disks via their serial numbers.
|
|
|
| Quote: | From: Poul-Henning Kamp <phk@phk.freebsd.dk
In message <20060627.103343.-432837786.imp@bsdimp.com>, "M. Warner Losh" writes
:
: devfs is not a hardware inventory facility, it is magic place for
: performing a rendez-vous with a device driver.
True, but somewhat irrelvant.
Not really, it has to be kept in mind to avoid decending into the
hell currently reserved for Linux procfs :-)
From the user/sysadmin perspective I must say that I really
love the Linux procfs. It makes the life so much easier. |
-SB
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Poul-Henning Kamp
*nix forums Guru
Joined: 21 Mar 2002
Posts: 436
|
| Posted: Tue Jun 27, 2006 6:43 pm Post subject:
Re: Accessing disks via their serial numbers.
|
|
|
In message <20060627.120424.-1625880159.imp@bsdimp.com>, "M. Warner Losh" write
s:
| Quote: | In message: <62122.1151427182@critter.freebsd.dk
"Poul-Henning Kamp" <phk@phk.freebsd.dk> writes:
: There is no problem with fully enumerated devices, as long as
: they don't cause an explosion in the number of devices.
That's my view as well! We agree!
|
Well, not quite, but lets leave the deep UNIX philosophy questions
behind for a moment.
| Quote: | : We have the devfs( rules for that.
And no way to audit them. The basic problem that I'd have in this
specific case (serial numbers ala some variation of /dev/ad/ABCDEFG)
is that the system administrator cannot set and verify the permissions
of the filename.
|
My take on this is different than yours.
I don't think we should allow names that are not "under control",
and by not "under control" I mean device names which the device
driver writer doesn't control or at the very least sanitize.
For instance, if you want to create names that match random
strings, like the tape labels in your robot, the sensible and
security concious device driver writer makes sure the names
have a unique prefix:
/dev/tape/$label
or similar, so that devfs( rules can be written in a surefire way.
| Quote: | A simple fix to this would be to have a sysctl that says to filter or
allow magic characters in the label name.
|
I really don't think it should be optional. A vis(3) in some
form should always happen.
| Quote: | : The reason why I am advocating using "on-demand" names for
: what Pawel is proposing is that way the names only exist
: if people ask for them, and only the names they ask for exists.
Making them on-demand makes it impossible to audit. Right now, if I'm
owrried abotu disk security, I can do:
|
That is why I'm not terribly keen on any kind of user-controlled
/dev filenames.
| Quote: | : In addition to avoiding a wanton doubling of the geom mesh
: size (because he does it at the very bottom) that also
: adds significant flexibilty and security to the table.
However, I'm not sure I understand the
flexibility and security side of things. Properly written and
implemented, I'm not sure how it affects security.
|
With an on-demand scheme, the scalability issue disappears,
so we can add hard labels, soft labels, physical position
(bus:id:lun), OEM labels, anything you can think off.
With a fully enumerated scheme, the scalability bites hard.
The only way to collapse these two views would be to allow
drivers to register directories in DEVFS, so that they get
to enumerate the issue when necessary, but without allocating
cdevs for all the unnessesary nodes.
That is heading straight down the Linux procfs path.
If we want to go that way: fine, personally I think it leads
to madness.
And please remember: This entire thing only comes up because
Pawel doesn't want to solve the problem correctly for g_label,
this is the fall-back "quick&dirty" solution.
The correct solution is to give the users a reliable tool for
stealing the necessary labelsector from the end of a filesystem.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Pawel Jakub Dawidek
*nix forums addict
Joined: 24 Jun 2003
Posts: 92
|
| Posted: Tue Jun 27, 2006 8:11 pm Post subject:
Re: Accessing disks via their serial numbers.
|
|
|
On Tue, Jun 27, 2006 at 06:43:19PM +0000, Poul-Henning Kamp wrote:
| Quote: | And please remember: This entire thing only comes up because
Pawel doesn't want to solve the problem correctly for g_label,
this is the fall-back "quick&dirty" solution.
|
If you are talking about restricting labels names here, I had the code,
but it was backed out. Please see the archives. I still doesn't like it.
| Quote: | The correct solution is to give the users a reliable tool for
stealing the necessary labelsector from the end of a filesystem.
|
I wrote this twice already in this thread, but let me write it again.
File systems are not the whole world. For example. I've a disk ad0.
I configured gbde(4) on top of it. I create file system on top of
ad0.bde. Now, let's assume I implemented shrinkfs( as you suggested,
how can I shrink gbde(4) provider?
--
Pawel Jakub Dawidek http://www.wheel.pl
pjd@FreeBSD.org http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am! |
|
| Back to top |
|
|
Garance A Drosehn
*nix forums beginner
Joined: 15 May 2005
Posts: 15
|
| Posted: Tue Jun 27, 2006 8:38 pm Post subject:
Re: Accessing disks via their serial numbers.
|
|
|
At 6:43 PM +0000 6/27/06, Poul-Henning Kamp wrote:
| Quote: |
I don't think we should allow names that are not "under
control", and by not "under control" I mean device names
which the device driver writer doesn't control or at the
very least sanitize.
For instance, if you want to create names that match random
strings, like the tape labels in your robot, the sensible
and security concious device driver writer makes sure the
names have a unique prefix:
/dev/tape/$label
or similar, so that devfs( rules can be written in a
surefire way.
|
This strikes me as a worthwhile idea. Leave the device-
entries in /dev as they are now, but then create some
sub-directories which would hold the more arbitrary (or
"non-sanitized") names.
/dev/info/disk/serial-num
or /dev/info/geom/whatever
etc. That way there's only one new entry in /dev, and
people could just de-permit that directory (or turn the
feature off) if they didn't want or need to have that
extra info available.
--
Garance Alistair Drosehn = drosehn@rpi.edu
Senior Systems Programmer or gad@FreeBSD.org
Rensselaer Polytechnic Institute; Troy, NY; USA
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Poul-Henning Kamp
*nix forums Guru
Joined: 21 Mar 2002
Posts: 436
|
| Posted: Tue Jun 27, 2006 8:48 pm Post subject:
Re: Accessing disks via their serial numbers.
|
|
|
In message <20060627201148.GC24054@garage.freebsd.pl>, Pawel Jakub Dawidek writ
es:
| Quote: | I wrote this twice already in this thread, but let me write it again.
File systems are not the whole world. For example. I've a disk ad0.
I configured gbde(4) on top of it. I create file system on top of
ad0.bde. Now, let's assume I implemented shrinkfs( as you suggested,
how can I shrink gbde(4) provider?
|
You can't.
Face it, somethings in life are not possible.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
John Baldwin
*nix forums Guru Wannabe
Joined: 27 Mar 2002
Posts: 278
|
| Posted: Wed Jun 28, 2006 2:36 pm Post subject:
Re: Accessing disks via their serial numbers.
|
|
|
On Tuesday 27 June 2006 16:11, Pawel Jakub Dawidek wrote:
| Quote: | On Tue, Jun 27, 2006 at 06:43:19PM +0000, Poul-Henning Kamp wrote:
And please remember: This entire thing only comes up because
Pawel doesn't want to solve the problem correctly for g_label,
this is the fall-back "quick&dirty" solution.
If you are talking about restricting labels names here, I had the code,
but it was backed out. Please see the archives. I still doesn't like it.
The correct solution is to give the users a reliable tool for
stealing the necessary labelsector from the end of a filesystem.
I wrote this twice already in this thread, but let me write it again.
File systems are not the whole world. For example. I've a disk ad0.
I configured gbde(4) on top of it. I create file system on top of
ad0.bde. Now, let's assume I implemented shrinkfs( as you suggested,
how can I shrink gbde(4) provider?
|
If you want a label you should label it before gbde(4). This is similar to
the fact that you can't retroactively add a gmirror under the gbde slice
either.
--
John Baldwin
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Fri Nov 21, 2008 2:50 am | All times are GMT
|
|
Credit Card | Loans | Home Loan | Mortgage Calculator | Buy Anything On eBay
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
BSD
»
FreeBSD
»
mail-lists
»
Architecture
