Les Mikesell wrote: > Mikkel L. Ellertson wrote: > >> It adds one more level of control. Instead of a user being able to >> access a device from anywhere, you can limit access to when they are >> actually at the machine. > > But the 'console' isn't something special in a multiuser system. > Personally, I do almost all Linux work through NX/freenx, remote X, or > ssh connections. I may be near enough to want to use speakers or CD > devices but not using the attached keyboard - if there is one. > So? there is nothing stopping you from doing this. But if there is a user logged into the console, then they are given the use of the device. It works well for most users, but if it does not work for you, change it for your system. That is what Linux is all about - you can configure things the way you like them. > >> For desktop users, it can be very useful. It can also be a >> security measure. > > If you throw away the concepts of remote access and multiuser operation. > How are you throwing them away? They are still there. But there is another concept added that works well for a lot of users. If you are working at the local machine, instead of doing remote access, you get the use of a configurable set of resources while you are logged in. If you have a machine that does not have a local console, it does not affect you. > > It's not _just_ that it has always been done that way - it was done that > way for good reasons and it doesn't make much sense to dumb down an > elegant system designed for multiuser and network access and pretend it > can only be accessed for certain things if you happen to be typing at a > certain keyboard. As an _option_ that you could active if you happen to > have that sort of situation and don't care about network/remote access > it would make sense, but it is throwing away a lot to pretend that it is > only designed to be used from one special device and make the other > things break by default. > I guess you have not looked at how it works, but decided you don't like it from what little was posted on the list. It is an option that has been around for a long time. It has been working well. What is giving people trouble is that it is not managing as many devices as it did in the past. For example, all serial ports were once controlled by console.perms. Now you have to specify the ports you want to control, or fall back on adding users to the uucp group, because the defaults are more restrictive. Now, you may want to disable console.perms package, because it is not of any benefit to you. But that does not mean it is of no benefit to the average user. You just have to put forth the effort to customize your system for the way you want it to work, instead of expecting Fedora to change to match the way you want to do things. But I expect that you will continue arguing that Fedora should do things your way, as you always do. So I am done with this thread. Mikkel -- Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup!
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
