Russell Coker writes:
> On Sat, 10 Nov 2001 18:11, Richard Gooch wrote:
> > Well, this shouldn't be necessary. I've already fixed the message to
> > reflect that it's stat(2) that's failing and not lstat(2). I'm
> > considering making the PERMISSIONS action ignore symlinks. Right now,
> > you can change permissions by going through a symlink. That would no
> > longer be possible. For example:
> > REGISTER discs/disc.*/disc PERMISSIONS 0.0 rw-r-----
> >
> > would no longer change the permissions of all whole-disc
> > entries. However, you could get the same effect with:
> > REGISTER .*/disc PERMISSIONS 0.0 rw-r-----
> >
> > since no non-disc driver should create a "disc" leaf node. Otherwise,
> > you'd need something like:
> > REGISTER scsi/.*/disc PERMISSIONS 0.0 rw-r-----
> > REGISTER ide/.*/disc PERMISSIONS 0.0 rw-r-----
> >
> > Comments?
>
> This sounds good. Now can I count on all whole-disk entries to
> match in /disc$ and all partitions to match /part[0-9]+$ and nothing
> to give a false match? Currently I have separate entries for IDE
> and SCSI and have been contemplating adding new entries for RAID
> controllers etc.
Well, I imagine you're pretty safe in relying on "disc" not being used
by anything/anyone else :-)
I would hope that no other driver wants to use part%d for some other
use. More importantly, I hope that no other driver just goes ahead and
does it.
An alternative is to add a "nowarn" option to the action. That way, it
will be silent on dangling symlink. There is a reason for favouring
this approach over ignoring symlinks in the PERMISSIONS action. By
ignoring symlinks, a certain flexibility is lost. The scheme I
mentioned above will work nicely for disc devices, and is probably OK
for CD-ROMs as well.
But consider tape devices. The leaf nodes are not as well defined
there, which is due to the definition of a variety of access
modes. This variety is likely to increase as new devices are
developed.
So, for tapes, it is much easier to use the /dev/tapes hierarchy,
which in turn means that ignoring symlinks in the PERMISSIONS action
would be detrimental. Which is why I said I'm just considering it,
rather than "I've done it" :-)
> > BTW: what config line do you have that wants to change the permissions
> > of "stdin", "stdout" and "stderr" anyway?
>
> Nothing any more.
>
> Once I made a mistake in a config file which matched ^st as SCSI
> tapes and changed stdin/stdout/stderr to mode 600 which for some
> reason I could not determine resulted in /dev getting mode 600 and
> the system being mostly unusable. The strange thing was that it
> didn't happen at initial start, only on signal 1.
Curious. Feel free to strace devfsd to narrow down this "effect"...
Regards,
Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current: rgooch@xxxxxxxxxxxxxxx
|