Well I've been lurking here for about a week so take anything I say with
a
grain of sugar.
Ny first foray into /dev was when trying to install a complete/generic
devfs
into an initrd ramdisk and or onto a 1.44m floppy. I naively thought
that because /dev entries appeared to be simply directory entries...
they would not take up that much space. I quickly found out otherwise
and had to resort to a custom setup that left me enough space to install
the programs that I needed.
I'll happily spend my nickel on a system that provides the maximum
amount of information in the least amount of space.
The two or three character tty, pty, hda, scd, ..etc is fine with me. As
is also the /proc system. Machine-readable/bit-twiddly or
verbose/human-readable (you can choose which you like to see) type of
format. No disk space is necessarily required as the textual information
is, or can be, provided by the hardware, drivers, or specific
application/utility programs by extension.
Will we ever again see the day when we had a 12KB kernel?
Personally I think that the problem of ACL's is best solved in another
area like PAM. The standard unix access security has always seemed to
me, to little or not enough for some reason. I guess that I would best
describe it as the simplest efficient compromise we can think of that
gets the job done. Either the system is (single user where there may be
no access restrictions on any part of the machine) or (it could be a
complex network of machines, groups, users, devices, applications,
functions, organizations, departments, compartments, ad infiniteum.
Where coporate security hierarchies can be uniquely varied and difficult
if not impossible to implement in the standard unix security model.) NIS
solves some of these problems, PAM solves some others, but to me access
security management over a large installed base of unix workstations has
always been a nightmare.
It would seem to me that here is where we might want to propose adding
the device access security thing. /pamdev or /devacc or /proc/devacc
(probably not) or /security. The idea that certain users or groups of
users can or can not have certain access permissions to an entity,
device, file, program, or directory in shared, exclusive, readonly,
writeonly, or whatever type of accessmode "DYNAMICALLY"...
I am probably all wet and way off base here, but why do we use symlinks
any way? Why can't we use hard links? Or worse yet, a socket? Do hard
links always have to carry the permissions of the file you link to? What
might likely be the performance implications of linking to a socket type
device?
Best Regards,
Chris.
Neil Brown wrote:
>
> Hi there all.
>
> There would still be a place for a devfsd like program, particularly
> for taking arbitrary action on hot-plug/unplug events, though
> probably for other things too. I would hope that the system could
> still work reasonably well without devfsd running though.
>
> This change would not be optional like devfs is as it substantially
> changes the way devices are handled. This would imply that we would
> want to be able to have a stripped down device filesystem for use in
> embedded systems. How much stripping down would depend on how much
> code it actually took to implement.
>
> One issue that this proposal doesn't directly resolve is allowing
> changes to permissions in /dev on a read-only root filesystem.
> However it doesn't provide for file creation in /tmp on a read-only
> root filesystem either:-) I like the 'copy /dev to a tmpfs, and then mount
> that on /dev' approach. I'm sure that other approaches are possible
> and could be "better", but I think the issue is separate from the
> issue of how to represent devices.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:19 EST