On 03/01/2012 08:38 AM, Roger Oberholtzer wrote:

On Thu, 2012-03-01 at 00:17 +0100, jdd wrote:

...

Le 29/02/2012 21:27, Roger Oberholtzer a écrit :

...

I think the issue is fine-grained permissions.

read man sudoer

* What fine-grained activities currently limited to root could have configurable access. Like my favorite: network broadcasts.

Hi Sorry to interfere, but Is that Wireshark? On ubuntu you can launch it as a user. On openSUSE only root can launch it. Or at least I've not found a way to do it. L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/01/2012 09:05 AM, jsa wrote:

On 02/29/2012 11:59 PM, lynn wrote:

...

On 03/01/2012 08:38 AM, Roger Oberholtzer wrote:

...

On Thu, 2012-03-01 at 00:17 +0100, jdd wrote:

...

Le 29/02/2012 21:27, Roger Oberholtzer a écrit :

...

I think the issue is fine-grained permissions.

read man sudoer

* What fine-grained activities currently limited to root could have configurable access. Like my favorite: network broadcasts.

Hi Sorry to interfere, but Is that Wireshark? On ubuntu you can launch it as a user. On openSUSE only root can launch it. Or at least I've not found a way to do it. L x

Wireshark uses promiscuous mode and should be root only.

But on ubuntu, I can run it as a user. Can I do that on 12.1? L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thu, 2012-03-01 at 15:34 +0100, Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2012-03-01 09:24, lynn wrote:

...

...

Wireshark uses promiscuous mode and should be root only.

But on ubuntu, I can run it as a user. Can I do that on 12.1?

You can probably suid the binary.

Yikes. To get perhaps one root capability, you give the application the world. Quite generous. As they say, with great power comes great responsibility. I just don't trust the general non-buggy-ness of things. Fine grained permissions seem a bit more secure. Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thu, Mar 01, 2012 at 09:28:47PM +0100, Carlos E. R. wrote:

On 2012-03-01 16:18, Roger Oberholtzer wrote:

...

On Thu, 2012-03-01 at 15:34 +0100, Carlos E. R. wrote:

...

...

You can probably suid the binary.

Yikes. To get perhaps one root capability, you give the application the world. Quite generous. As they say, with great power comes great responsibility. I just don't trust the general non-buggy-ness of things. Fine grained permissions seem a bit more secure.

There is no other way of running it, and this is the kernel fault.

Perhaps it could be made a two part program: a small one running as root and doing the capturing part, and another doing the gui and processing. But this doesn't exist.

And on wireshark now and then there have been found security holes.

Read up on filesystem capabilities here. ... Basically attributes added within the filesystem that only give some of the capabilities. But wireshark as a X client really shouldn't be setuid root. If you need it, "su", "sudo" or "ssh -X root@localhost" to run it. Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

01.03.2012 11:59, lynn пишет:

On 03/01/2012 08:38 AM, Roger Oberholtzer wrote:

...

On Thu, 2012-03-01 at 00:17 +0100, jdd wrote:

...

Le 29/02/2012 21:27, Roger Oberholtzer a écrit :

...

I think the issue is fine-grained permissions.

read man sudoer

* What fine-grained activities currently limited to root could have configurable access. Like my favorite: network broadcasts.

Hi Sorry to interfere, but Is that Wireshark? On ubuntu you can launch it as a user. On openSUSE only root can launch it. Or at least I've not found a way to do it. L x

Wireshark? Interesting. If I start it using double click on icon on desktop when it asks me root password. If I open konsole and type wireshark when it doesn't ask me password. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thu, Mar 01, 2012 at 11:27:36AM +0100, Roger Oberholtzer wrote:

On Thu, 2012-03-01 at 08:59 +0100, lynn wrote:

...

On 03/01/2012 08:38 AM, Roger Oberholtzer wrote:

...

On Thu, 2012-03-01 at 00:17 +0100, jdd wrote:

...

Le 29/02/2012 21:27, Roger Oberholtzer a écrit :

...

I think the issue is fine-grained permissions.

read man sudoer

* What fine-grained activities currently limited to root could have configurable access. Like my favorite: network broadcasts.

Hi Sorry to interfere, but Is that Wireshark? On ubuntu you can launch it as a user. On openSUSE only root can launch it. Or at least I've not found a way to do it.

It is software and, more importantly, libraries provided by equipment vendors. For example, these companies provide SDKs for Linux that have as part of their procedure the desire to do a network broadcast to locate things:

SICK AG (http://www.sick.com)

JAI A/S (http://www.jai.com/en/)

Allied Vision Technologies (http://www.alliedvisiontec.com/emea/home.html)

Basler (http://www.baslerweb.com)

LMI Selcom (http://www.lmi3d.com/)

There are many more. They too complain that Linux sometimes makes it more difficult to implement transducer queries than 'the other OS'. Their techniques are similar to mDNS and such things.

I would use these in my application, as one does. I do NOT repeat NOT want to run measurement software as root just to satisfy this need.

But this is not really related to the topic of Desktop security that Linus was mostly ranting about. (I do not exactly understand the issues at hand here though.) Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Roger Oberholtzer wrote:

Well, these suppliers provide, quite often, QT apps that allow one to configure their devices. They need to first locate them. A network broadcast is what they would like to do. Except on Linux this requires root permissions.

I'm not at all sure, but isn't this managed with capabilities? There is a CAP_NET_BROADCAST (although the man page says "unused"). -- Per Jessen, Zürich (9.3°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Roger Oberholtzer wrote:

On Thu, 2012-03-01 at 13:02 +0100, Per Jessen wrote:

...

Roger Oberholtzer wrote:

...

Well, these suppliers provide, quite often, QT apps that allow one to configure their devices. They need to first locate them. A network broadcast is what they would like to do. Except on Linux this requires root permissions.

I'm not at all sure, but isn't this managed with capabilities? There is a CAP_NET_BROADCAST (although the man page says "unused").

You have my attention. Where is this?

Well, maybe start with "man capabilities". I think that is where I saw CAP_NET_BROADCAST mentioned. I have never played with any of this, but my understanding is that you can manage various capabilities on a per-process or per-user basis. I'm grasping at straws, but I'm sure somebody here will have an actual understanding of this. -- Per Jessen, Zürich (11.2°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thu, 2012-03-01 at 19:53 +0000, Jim Henderson wrote:

On Thu, 01 Mar 2012 14:52:43 +0100, Per Jessen wrote:

...

Well, maybe start with "man capabilities". I think that is where I saw CAP_NET_BROADCAST mentioned. I have never played with any of this, but my understanding is that you can manage various capabilities on a per-process or per-user basis. I'm grasping at straws, but I'm sure somebody here will have an actual understanding of this.

From what I understand, kernel capabilities are disabled selectively - you start a program as root and it has access to everything, and then the program (perhaps also an external process can do this - that I don't know) disables what the program shouldn't be allowed to do.

The kernel does this. If the UID is 0 (root) some set of permissions are enabled. If not 0 (not running as root) a different default set are enabled. The 'capabilities' mechanism allows extension of what non 0 UID apps can do. The permissions, it seems, are stored in the file system along with the executable (see 'man capabilities'). So, I would imagine it requires either a specific file system, or that additional file system options be enabled. The man page is rather vague. Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Jim Henderson wrote:

The way I read the man page, it's possible to set capabilities for a particular program using a file in the filesystem (just a config file),

Do you happen to know which file? I also thought it would be something like this, but I cannot figure which file it might be. (so I'm leaning towards extended attributes for an executable or starting with root, then dropping privileges before exec()ing). -- Per Jessen, Zürich (10.6°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Hello, On Mar 1 12:18 Roger Oberholtzer wrote (excerpt):

... the root problem (pun intended) remains. What is needed is a general approach to these permissions.

If the use case is "printer setup on my own machine", I think - but I am not at all a security expert - it should be an acceptable solution when the normal user's password and the root password are the same so that from the user's point of view there is just one password i.e. THE password. Then configuration changes could still require THE password which is - from my point of view - sufficiently easy to use and sufficiently secure because: - The owner of the machine can do any configuration changes, he only must provide THE password. - The owner of the machine cannot do configuration changes by accident because he must provide THE password. - Arbitrary persons who get access to the machine cannot do configuration changes (i.e. arbitrary persons cannot hijack the machine when it is running unattended). As far as I noticed what other wrote in this thread, this could be even already the default when installing an openSUSE system. If yes I wonder what the whole discussion is about? Does anybody really want that arbitrary persons are allowed by default to do configuration changes? I assume nobody wants this. Therefore I assume what is wanted is that not only one person is allowed by default to do configuration changes but that it is possible to allow particular other users (e.g. the owner of the machine and his best friend) to do particular configuration changes. As far as I know this is currently not possible. If this is wanted, a FATE feature request should help... Hint: https://features.opensuse.org/

As to the printer things: isn't it mainly configuration file access that is the problem?

No. Print queue related configuration files are written by the cupsd which has the right permissions to deal with its own files. Please see the documentation, in particular have a look at "General information on the command-line tools" and "Allow printer admin tasks for a normal user" at http://en.opensuse.org/SDB:CUPS_in_a_Nutshell Regarding CUPS policies, have a look at the YaST printer module. By the way: As far as I understand Vincent Untz' comment https://bugzilla.novell.com/show_bug.cgi?id=749451#c3 this could be - from my point of view - a major security issue when the Gnome desktop printer setup tool system-config-printer does not work in compliance with the CUPS "Operation Policies" but uses instead its own kind of "provide admin permissions" tool cups-pk-helper. Assume someone has set up his own computer and thinks it is secure against configuration changes so that he can let someone else work on his computer - but actually this other person can change the print queues via the Gnome desktop so that all (possibly confidential) print jobs print as usual (so that the betrayal is not easily noticed) but additionally it sends a copy of what is printed to an external destination. I hope that by default this is currently not possible but I think many ask for such a default. And vice versa: Assume someone has set up the CUPS operation policy "allowallforanybody" so that anyone can do any printing stuff but this does not work under the Gnome desktop because the Gnome desktop printer stuff does not work in compliance with the CUPS "Operation Policies". I did not test if this is actually the case. I only like to point out that it is in general a bad idea when a desktop environment would do such stuff on its own. Generally: It is a very bad idea when whatever kind of higher-level programs do not work in compliance with the underlying lower-level stuff. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Hello, (Lars, why did you leave out the salutation?) On Mar 1 17:27 Lars Müller wrote (excerpt):

On Thu, Mar 01, 2012 at 02:53:26PM +0100, Johannes Meixner wrote:

...

If the use case is "printer setup on my own machine", ... - The owner of the machine can do any configuration changes, he only must provide THE password.

Even with a single user you might not like to share the root password.

Either I do not understand what you write or you do not understand what I wrote. I meant that the user who works on the machine and its owner are one same person. In this case I do not understand what you mean with "not share the root password"? How should one same person not share all passwords which he has in his one same brain?

The discussiion is not about arbitrary people. It's about existing users which must not have root access.

Users which must not have root access must not be allowed to change the print queues. It really helps to read the documentation or at least read what our security experts wrote. It really helps to get some basic background knowledge about an issue to be able to contribute something useful to make it move forward instead of only repeating again and again same old nonsense.

...

https://features.opensuse.org/

Oh the feature pat cemetry. That's such a good place to get people shut up. ;) I'm quite sure if it got filed there we'll see it addressed in 2020. Maybe.

I don't know what a "pat cemetry" is - did you mean "cemetery"? But what do you mean with "pat" in this case? Regardless what you actually meant, I think issues with FATE are off-topic here. Please start a new mail thread or file a Bugzilla bug report or file a FATE feature request in such cases.

Wouldn't it be much easier to allow all local users to modify the cups configuration if the administrator prefers this?

What exactly is a "local user"? Unix user accounts do not distinguish between "local" and "remote".

Again, we should not set this by default. But on request by the adim from inside the YaST install/ printer setup dialog.

Do you mean a YaST printer setup dialog to set up what I described at "Allow printer admin tasks for a normal user" in http://en.opensuse.org/SDB:CUPS_in_a_Nutshell If yes, please file a FATE feature request. Do not file a bug report because missing features are no bugs (I would have to close such a bug report as "invalid). For those who my wonder why I insist on a FATE feature request: Without a FATE feature request that is approved by management I will not get any time at all to implement anything new for openSUSE. The reason is that by default work for business products (SUSE Linux Enterprise Server/Desktop and so on - i.e. stuff where our customers pay for which pays in the end my salary) has higher priority than work for openSUSE - and of course there is always work to be done for business products... For our business products there is no such feature request. I guess because admins in the corporate world read the documentation and just do what I described at "Allow printer admin tasks for a normal user" in http://en.opensuse.org/SDB:CUPS_in_a_Nutshell I guess those admins do not need a GUI for printing system configuration. Therefore you - the openSUSE people - must contribute your part which is in this case: File a FATE feature request and make it sufficiently known to those who decide about openSUSE features and keep involved with it to get it decided as you need. This is my last mail regaring this issue. Any further working time which I spend on this issue requires that an appropriate FATE feature request exists. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer

Jim Henderson wrote:

On Fri, 02 Mar 2012 10:01:32 +0100, Johannes Meixner wrote:

...

...

The discussiion is not about arbitrary people. It's about existing users which must not have root access.

Users which must not have root access must not be allowed to change the print queues.

Surely that's a decision for the owner of the machine (whether an individual or a corporation) to make.

Say, for example, I work for a consulting organisation, and their IT department decides the consultants shouldn't have root access to their machines.

If I go to a client site, I shouldn't be able to configure a printer so I can print things at the client site?

Perhaps, but in my experience (banking, airlines, IT) the client site is unlikely to allow foreign equipment on their network. -- Per Jessen, Zürich (10.4°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen wrote:

...

If I go to a client site, I shouldn't be able to configure a printer

...

so I can print things at the client site? Perhaps, but in my experience (banking, airlines, IT) the client site is unlikely to allow foreign equipment on their network.

In my work for that insurance company, they provided me with the computer. I do my work at agent's offices and am expected to be able to use the local printer. In this situation, the agent owns the local network and hardware and connects to the corporate network. I am expected to configure my computer to use the agent's local printer. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Dave Howorth wrote:

There's been a huge amount of discussion in this thread about many different use cases. But I don't think requirements analysis is really the difficult bit. I think Werner's right.

Does anybody have any concrete suggestion for how the system should behave? (Or better yet, some code to implement it! :)

(a) What options should there be at install time? (and as a minor subquestion, what should be the default?)

(b) What facilities should the be as an administrator? (For each possibility in (a))

What facilities should be available while logged in as a normal user, within each environment set by (a) and (b)?

Cheers, Dave

Given that notebook computers are intended to be used in different locations, then it should be possible for users, without root password to use local WiFi and printers. If the employer decides that those are not to be permitted, then it should be their choice. This means that the policy should be configurable and I would suggest make the default that those connections are permitted. For openSUSE to simply say you're not allowed to do that without root password is flat out wrong, stupid and arrogant. As I have mentioned before, with the current policy, I would not be able to do the work that I have been hired to do. That's the reality of the situation and it is that bad! You seem to think Werner is correct. Please justify why I should not be allowed to do my work. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Dave Howorth wrote:

Werner said:

...

...

OpenSUSE is a community project and you're welcome as a member to find and/or provide a manageable and secure solution for both a one user or shared users systems as well as for real multi user systems. I fail to see how that bears any relation to whether you can do your work.

My work requires me to use my computer at various locations and occasionally in hotels. When on site, I am expected to configure my computer to use a local printer and also be able to use the WiFi in the hotel or elsewhere. If I cannot do both of these, I am unable to properly do the work I have been hired to do. This is with a computer provided by the company I'm doing the work for and I do not have admin or root access. With openSUSE 12.1, I would not be able to use WiFi or printers as described above. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Jim Henderson wrote:

On Fri, 02 Mar 2012 13:23:13 +0000, Dave Howorth wrote:

...

There's been a huge amount of discussion in this thread about many different use cases. But I don't think requirements analysis is really the difficult bit. I think Werner's right.

Does anybody have any concrete suggestion for how the system should behave? (Or better yet, some code to implement it! :)

I suggested that there be a few security profiles - a low security, medium security, and high security profile.

Along with a tool that's easy to use to tweak the policykit policies in the event that one of the presets doesn't meet the needs precisely enough.

Purely a tangent here, but at least security policy related - a while ago, I created a FATE request suggesting we alter the default settings in the GUI to 1) always enable to screen-saver, 2) always require password when locked and 3) prevent the user from disabling the screen saver. It wasn't met with great approval :-(

Default to the medium security profile. Let the user pick an option at install time, and give them a YaST module to change it if it's too restrictive (or not restrictive enough).

The user should be able to see what the policy currently lets them do.

+1 -- Per Jessen, Zürich (15.1°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

C wrote:

On Fri, Mar 2, 2012 at 15:04, Per Jessen <per@opensuse.org> wrote:

...

Purely a tangent here, but at least security policy related - a while ago, I created a FATE request suggesting we alter the default settings in the GUI to 1) always enable to screen-saver, 2) always require password when locked and 3) prevent the user from disabling the screen saver.  It wasn't met with great approval :-(

And not much wonder. While that might make sense on a corporate desktop (I've had at least one employer enforce that exact scenario), if you try to do that on my desktop computer... I'll be VERY grumpy.

I think it makes as much sense at home as at work. Especially when you've kids, spouse and other family around who perhaps share the laptop on occasion. But I guess the response was an indication that people who check FATE are mostly home users.

I do not use a screensaver at all at home... and the computer is never "locked". The very first thing I do after an install is disable the screensaver.

I use my main desktop for work as well as home use - I always enable lock. I don't want anyone accidentally hitting the wrong key etc.

If the user was prevented from disabling the screensaver (requiring root or whatever to config), you would have a MUCH bigger outcry than a Linux guru grumping about printer configs and WiFi.

The user would have the option to enable/disable this at install time.

That is a great idea in my view... if we could decide on what is in each... and ensure that low isn't so low as to introduce a major security hole... this could be a nice solution. It has the potential to make everyone happy... including people who want a permanent screensaver with password requirement :-)

Let's hope we can find someone to willing to implement it too .... -- Per Jessen, Zürich (16.3°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Basil Chupin wrote:

On 03/03/12 01:04, Per Jessen wrote:

...

Purely a tangent here, but at least security policy related - a while ago, I created a FATE request suggesting we alter the default settings in the GUI to 1) always enable to screen-saver,

This is already enabled on installation - and the first thing I do is rid myself of this PITA because the screensaver keeps kicking in at the most inappropriate times when, say, I am doing an update to the system and I am about to respond to some input request.

Besides, this screensaver idea belongs to the 50s era when the screen was likely to get a "burn in" which no longer applies and hasn't applied for decades. How can you get a "burn in" on an LCD monitor?

It's obviously not about preventing burn-in. The name might belong in the 50s, but the protection of information is needed today. The power saving feature is perhaps less topical today.

...

2) always require password when locked

This, also, is the default: lock the screen and you have to enter your password to "un-blank" it.

I'll have to double check that - I'm sure it was not default (in KDE) when I wrote that FATE entry.

I HATE the screensaver - it is a PITA. It belongs to the dark ages, and if I cannot disable it I would then be forced to switch over to Windows.

In the business/corporate environment, in particular where personal or otherwise confidential data is being processed, it's an absolute must. Anyway, it's just a feature that we should set depending on the security level chosen at installation time. -- Per Jessen, Zürich (7.8°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Basil Chupin wrote:

...

...

...

2) always require password when locked This, also, is the default: lock the screen and you have to enter your password to "un-blank" it. I'll have to double check that - I'm sure it was not default (in KDE) when I wrote that FATE entry.

Lock the screen; hit any key or move the mouse and enter your password at the menu - and your desktop is once again displayed.

Been like this for years as far as I am concerned.

...

I HATE the screensaver - it is a PITA. It belongs to the dark ages, and if I cannot disable it I would then be forced to switch over to Windows. In the business/corporate environment, in particular where personal or otherwise confidential data is being processed, it's an absolute must.

Again how so? The screen saver activates after a certain set period.

Yes, but the user has the option to disable it. Also, in my experience, the box "Password required" is not ticked by default, but that could have changed.

This is no protection for confidential data on the screen - what you need for this is the Lock function which is activated at your chosen time; that is, immediately you select to Lock and blank the screen. And you don't even have to ask anyone to turn their backs to the screen while you wait for the screen saver to kick in.

Maybe I am missing some significant difference between "lock" and "activate screensaver"? Does KDE have different settings for lock and screensaver? -- Per Jessen, Zürich (13.1°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/03/12 23:33, Per Jessen wrote:

Per Jessen wrote:

...

Basil Chupin wrote:

...

...

...

...

2) always require password when locked

This, also, is the default: lock the screen and you have to enter your password to "un-blank" it. I'll have to double check that - I'm sure it was not default (in KDE) when I wrote that FATE entry. Lock the screen; hit any key or move the mouse and enter your password at the menu - and your desktop is once again displayed.

Been like this for years as far as I am concerned.

...

I HATE the screensaver - it is a PITA. It belongs to the dark ages, and if I cannot disable it I would then be forced to switch over to Windows. In the business/corporate environment, in particular where personal or otherwise confidential data is being processed, it's an absolute must. Again how so? The screen saver activates after a certain set period. Yes, but the user has the option to disable it. Also, in my experience, the box "Password required" is not ticked by default, but that could have changed. I have just created a new user on a 12.1 desktop system. The screen- saver is active by default, but can be disabled by the user. Also, the "require password" box is not ticked.

Configure Desktop -> Display and monitor -> Screensaver

If the user locks the screen, a password is required to unlock (by default), so there _is_ a difference between "lock" and "activate screen-saver".

I think I can see a stumbling block emerging here.... :-) . I think that we are talking about 2 difference versions of KDE and probably 2 different ways we are using the Desktops/Workspaces. I am using, and talking about, KDE 4.8.x (latest updates to it) as well as NOT using the Folder View for the 6 Desktops I have but have separate Activities/Widgets for each Desktop/Workspace. For example, I do not see what you just referred to which is "Configure Desktop". In 4.8.00 (Release 462) I see "Desktop Settings". Which version of KDE are you using? And do you use the Folder View? This is what my Desktops (well one of them) looks like: http://susepaste.org/35961810 BC -- The vulgar crowd always is taken by appearances, and the world consists chiefly of the vulgar. Niccolo Machiavelli -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/03/12 01:01, Per Jessen wrote:

Basil Chupin wrote:

...

On 03/03/12 23:33, Per Jessen wrote:

...

I have just created a new user on a 12.1 desktop system. The screen- saver is active by default, but can be disabled by the user. Also, the "require password" box is not ticked.

Configure Desktop -> Display and monitor -> Screensaver

If the user locks the screen, a password is required to unlock (by default), so there _is_ a difference between "lock" and "activate screen-saver". I think I can see a stumbling block emerging here.... :-) .

I think that we are talking about 2 difference versions of KDE and probably 2 different ways we are using the Desktops/Workspaces.

I am using, and talking about, KDE 4.8.x (latest updates to it) as well as NOT using the Folder View for the 6 Desktops I have but have separate Activities/Widgets for each Desktop/Workspace. I am using vanilla 12.1+updates - KDE 4.7.2.

...

For example, I do not see what you just referred to which is "Configure Desktop". In 4.8.00 (Release 462) I see "Desktop Settings". Those are two different things, afaict. "Configure Desktop (Personal Settings)" is found on the start menu when you kick the gecko.

...

Which version of KDE are you using? And do you use the Folder View? KDE 4.7.2. If "Folder View" is the default, I'm using it.

...

This is what my Desktops (well one of them) looks like:

http://susepaste.org/35961810 My background is just vanilla green openSUSE.

Ah, we are in a way talking apples and oranges here then. Many things have improved with 4.8 being released to what they are in 4.7. BC -- The vulgar crowd always is taken by appearances, and the world consists chiefly of the vulgar. Niccolo Machiavelli -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Basil Chupin wrote:

I don't understand why a password would be required to disable the screensaver.

Not to disable, to unlock after it has kicked in.

...

This is no protection for confidential data on the screen - what you need for this is the Lock function which is activated at your chosen time; that is, immediately you select to Lock and blank the screen. And you don't even have to ask anyone to turn their backs to the screen while you wait for the screen saver to kick in. Maybe I am missing some significant difference between "lock" and "activate screensaver"? Does KDE have different settings for lock and screensaver?

Aren't you using KDE?

Yup, I'm on KDE.

But if you are using KDE then there is a difference between Lock and Screensaver.

Sofar I have been using "Lock" and "Screensaver[any]" interchangeably. I don't care which one it is as long as (we have a security profile in which) auto-lock/screen-saver: 1) is enabled by default with a reasonable timeout, 2) cannot be disabled 3) always requires a password to unlock. For me this setting is applicable for home use as well as in the office, but I accept that not everyone would want it at home. Maybe the proposed security profile ought to be divided by intended usage instead of level. -- Per Jessen, Zürich (13.4°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/03/12 00:10, Per Jessen wrote:
> Per Jessen wrote:
>
>> Sofar I have been using "Lock" and "Screensaver[any]" interchangeably.
>> I don't care which one it is as long as (we have a security profile in
>> which) auto-lock/screen-saver:
>>
>> 1) is enabled by default with a reasonable timeout,
>> 2) cannot be disabled
> 2) can only be disabled by root


What I am finding very hard to come to grips with is this need to not 
only be unable to disable the screensaver but also to have a root 
password when it is to be disabled.

Why is the screensaver such an important feature?

The only useful thing for which I have ever used a screensaver is to 
have the darn thing running when I wanted to impress someone visiting me 
to show off my monitor screen with some flashing or otherwise graphics - 
and no more.

The darn screensaver is using the cpu (and the gpu) to generate stuff on 
the monitor - and this is heating up the cpu which otherwise can sit 
quietly and resting.

In one moment of madness some years ago I installed a screensaver called 
The Aquarium - or some such. A screen-full of swimming fish in a salt 
water aquarium with a starfish moving (slowly) around the interior of 
the aquarium; and one also could configure it to emulate night and day. 
VERY pretty - especially to me as I had an aquarium when I was 9 years 
old (and when I grew up :-) ) and I enjoyed watching it.

But what I also noticed is that the temperature of the cpu went up by 
10C while this screensaver was running. Having noticed this I 
uninstalled this screensaver.

But I digressed......

Could you perhaps give an example of why you consider that the 
screensaver is so important and why it would require a root password to 
disable it? All in the cause of educating me of course :-) .

BC

-- 
The vulgar crowd always is taken by appearances, and the world consists chiefly of the vulgar.
                    Niccolo Machiavelli

-- 
To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org
To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/03/12 00:53, Per Jessen wrote:
> Basil Chupin wrote:
>
>> On 04/03/12 00:10, Per Jessen wrote:
>>> Per Jessen wrote:
>>>
>>>> Sofar I have been using "Lock" and "Screensaver[any]"
>>>> interchangeably. I don't care which one it is as long as (we have a
>>>> security profile in which) auto-lock/screen-saver:
>>>>
>>>> 1) is enabled by default with a reasonable timeout,
>>>> 2) cannot be disabled
>>> 2) can only be disabled by root
>>
>> What I am finding very hard to come to grips with is this need to not
>> only be unable to disable the screensaver but also to have a root
>> password when it is to be disabled.
>>
>> Why is the screensaver such an important feature?
> (screensaver or auto-lock).
> Protection of information.  People forget to lock their screen when they
> go to drink coffee or smoke a cigarette. Having an office PC
> auto-locked after X minutes reduces the window of risk.  What people
> would like displayed instead of their desktop is immaterial, blank
> screen, acquarium, banner, whatever.
>
>> The darn screensaver is using the cpu (and the gpu) to generate stuff
>> on the monitor - and this is heating up the cpu which otherwise can
>> sit quietly and resting.
> Screensaver could be = blank screen.
>
>> Could you perhaps give an example of why you consider that the
>> screensaver is so important and why it would require a root password
>> to disable it? All in the cause of educating me of course :-) .
> For the first, see above. Second, disabling it should require root
> access because it is a security and/or policy feature.  Changing the
> screensaver to<whatever>  should be left to the user.

I am getting the feeling that you are arguing here from the point of 
view of the principle of the thing rather than anything else :-) .

In a normal office environment nobody is doing anything which other 
colleagues are not also doing.

The only situations where such "not for anyone else's eyes" scenarios 
could come into play are where someone is doing very confidential work. 
In which case that person should be allocated a room to work in and 
which is (a) not accessed by other colleagues and/or (b) in an area 
where any member of the public is not allowed access; as well as this, a 
person to whom such a serious task has been assigned would not be 
someone who just walked off the street but would be a trusted and 
intelligent person specially selected to do this confidential work.

Ok, but let's say that this screensaver thing is operational on the 
basis which you want it to be. After how many minutes would you want the 
screensaver to kick in? 1 minute? 2 minutes? 10 minutes?

Let's say a person keeps getting phone calls from clients. Everytime he 
answers the phone the screenblanks after 1 minute or 2 minutes - but he 
has something on the screen which he has to use to answer the client's 
question but while he is talking to the client the bloody screen blanks. 
And he has to put down the phone and type in his password. Or say to the 
client, "Just a moment please while I re-activate my screen". After 
several such incidents the fellow will stop answering the phone!

But if the screensaver cuts in after, say, 10 minutes after the user 
goes off to have his cigarette or get a cup of coffee, what is there to 
stop anyone walking up to the monitor and looking at the screen before 
it, say, blanks? :-)

BC

-- 
The vulgar crowd always is taken by appearances, and the world consists chiefly of the vulgar.
                    Niccolo Machiavelli

-- 
To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org
To contact the owner, e-mail: opensuse+owner@opensuse.org

On 3/2/2012 8:56 PM, Basil Chupin wrote:

Besides, this screensaver idea belongs to the 50s era when the screen was likely to get a "burn in" which no longer applies and hasn't applied for decades. How can you get a "burn in" on an LCD monitor?

Pro Tip: google everything you are about to say just before you say it from now on. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sun, 11 Mar 2012 17:29:50 +1100 Basil Chupin <blchupin@iinet.net.au> wrote:

On 07/03/12 15:52, Brian K. White wrote:

...

On 3/2/2012 8:56 PM, Basil Chupin wrote:

...

Besides, this screensaver idea belongs to the 50s era when the screen was likely to get a "burn in" which no longer applies and hasn't applied for decades. How can you get a "burn in" on an LCD monitor?

Pro Tip: google everything you are about to say just before you say it from now on.

Thanks for the above.

Please, try with this article: http://www.pcmag.com/encyclopedia_term/0,2542,t=screen+burn&i=50904,00.asp Now we need only one more piece of information: "Is my (your) monitor the one that doesn't need screen saver?" It is obvious that this digression to ghost images is not addressing any security relevant concern, so I'll stop here. All messages related to screen saver use and its password protection did not brought consent what default should be. Per use case: It should run, have short time to start and it should be password protected. Basil use case: It should be disabled all together. Brian use case: It should be enabled. My use case: It should be enabled, with long time to start, and no need for password protection. We can list more use cases that will cover all other combinations of settings. As there is no single use case that fits all of us, and there is no statistics about openSUSE usage, we can leave default as is and quit this part of discussion. Or, we can continue and confirm theory that amount of time spent in discussion is inverse proportional to its importance for the subject. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Grr partially worded wrong, the strobe frequency is not altered just in regions but everywhere, only the brightness is altered in regions. The strobe feature has no bearing on screen savers I can see. The point was more simply that screen tech in general and including lcd's particularly, changes all the time and is essentially unpredictable and so no one can say we don't need screensavers any more because lcd's are common and lcd's don't need them. -- bkw -----Original Message----- From: brian@aljex.com Sent: Sunday, March 11, 2012 7:01am To: opensuse@opensuse.org Subject: Re: [opensuse] Re: Should openSUSE review it's Security Policies? -----Original Message----- From: "Basil Chupin" <blchupin@iinet.net.au> Sent: Sunday, March 11, 2012 1:29am To: opensuse@opensuse.org Subject: Re: [opensuse] Re: Should openSUSE review it's Security Policies? On 07/03/12 15:52, Brian K. White wrote:

On 3/2/2012 8:56 PM, Basil Chupin wrote:

...

Besides, this screensaver idea belongs to the 50s era when the screen was likely to get a "burn in" which no longer applies and hasn't applied for decades. How can you get a "burn in" on an LCD monitor?

Pro Tip: google everything you are about to say just before you say it from now on.

Thanks for the above. To quote from something (found using another search engine other than google), I quote the following: QUOTE LCD Further information: LCD and LCD TV Pros: Very compact and light Low power consumption, generally speaking. On average, 50-70% less energy is consumed than CRT monitors. [2] No geometric distortion. Little or no flicker depending on backlight technology. Not affected by screen burn-in (though an analogous but less severe phenomenon known as image persistence is possible). Can be made in almost any size or shape. No theoretical resolution limit UNQUOTE Note the 5th line of the "Pros" list, to wit: "Not affected by screen burn-in (though an analogous but less severe phenomenon known as image persistence is possible)." And for your edification this comes from here: https://en.wikipedia.org/wiki/Comparison_CRT,_LCD,_Plasma BC -- The vulgar crowd always is taken by appearances, and the world consists chiefly of the vulgar. Niccolo Machiavelli -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org -------- I already knew all that, thus the suggestion. Why do I get the feeling that after actually looking it up you still think an lcd screen has no use for a screen saver? Also all lcd's aren't the same and unpredictable things change all the time as far as how they're made and how they wear. My TV is lcd and has contrast and motion enhancement features that alter the backlight brightness and strobe frequency in different regions to match the picture. So now you have the potential for some backlight elements to burn more than others, maybe burning out sooner or increasing chances of one row/column to burn out, than the rest, even if the light output quality/performance never changes over time. No reason a monitor couldn't have the same features. Then you have oled's starting to appear which emit light directly and they degrade relatively quickly. Each pixel has a sort of half-life it uses up whenever it is on, and depending on how bright. So, for a variety of reasons, it's wrong to say that today a distribution doesn't need to enable a screen saver by default. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tue, 2012-03-06 at 22:54 -0500, Brian K. White wrote:

...

...

If I go to a client site, I shouldn't be able to configure a printer so I can print things at the client site?

Perhaps, but in my experience (banking, airlines, IT) the client site is unlikely to allow foreign equipment on their network.

The fact that some sites are secured from guests doesn't matter at all.

Other sites are not only open to, but expressly exist for, guests. And many sites of course have both a secure and a guest network and it's a growing not a declining trend.

Our company provides a 'guest' wireless network so visitors can access the outside world. They get no access to internal things from this access point. But they need to configure their computers to make this all happen. Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen wrote:

Right, that's how some IBM sites used to work too (a while back when I worked in that area).

Same in the City of Mississauga, Ontario public buildings (libraries, community centers, etc.). All you need to connect is a library card number. Many access points support multiple SSIDs and VLANs to enable this. In fact, a few years ago, I set up a network at a senior's residence. There were two SSIDs enabled. One for the staff allowed access to the business network and the other for residents and visitors to access the Internet. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

You completely fail. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Johannes Meixner wrote:

On Mar 2 15:51 Johannes Meixner wrote (excerpt):

...

You completely fail.

I am sorry.

Mind giving us a hint as to what you're referring to? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Johannes Meixner wrote:

If the use case is "printer setup on my own machine", I think - but I am not at all a security expert - it should be an acceptable solution when the normal user's password and the root password are the same so that from the user's point of view there is just one password i.e. THE password.

Not in the corporate world. Business employees generally do not get root or admin access to their computers. The whole idea of root vs user is to limit what a user can do. If they have the root password, you've lost that. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Jim Henderson wrote:

On Thu, 01 Mar 2012 14:27:17 -0500, James Knott wrote:

...

Business employees generally do not get root or admin access to their computers. Arguably, working around that is trivial regardless of the OS. There really is no security when the user has physical control of the device, regardless of the OS.

With Linux, give anyone a grub menu and nothing else, and it's trivial to get to a root prompt and change the root password.

Jim

I guess you've never worked in a corporate environment, where employees can be disiplined for violating IT policy. If you "work around" something like a root or admin password, then you're inviting disiplinary action. In general, corporate employees do not get root or admin password and for good reason. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thu, 01 Mar 2012 15:26:47 -0500, James Knott wrote:

Jim Henderson wrote:

...

On Thu, 01 Mar 2012 14:27:17 -0500, James Knott wrote:

...

Business employees generally do not get root or admin access to their computers. Arguably, working around that is trivial regardless of the OS. There really is no security when the user has physical control of the device, regardless of the OS.

With Linux, give anyone a grub menu and nothing else, and it's trivial to get to a root prompt and change the root password.

Jim

I guess you've never worked in a corporate environment, where employees can be disiplined for violating IT policy.

I spent 15 years working in corporate IT environments as a systems engineer, with company sizes ranging from < 200 employees to > 250,000 employees. Just because employees can be disciplined for violating IT policy doesn't mean (a) that they don't work around security measures put in place, or (b) that such discipline actually happens, even though it's a possibility. The threat of action is usually sufficient to keep most employees in line, but there are always those who flaunt the policies (some very visibly) either because they feel they're untouchable or because - believe it or not - they *are* untouchable (ever had an executive who felt that because it was his company, he shouldn't be subject to the rules? I have. Just try and have disciplinary action taken against people in management - in a lot of companies, that's a way to get sacked.)

If you "work around" something like a root or admin password, then you're inviting disiplinary action. In general, corporate employees do not get root or admin password and for good reason.

Sure, they don't, but not everybody plays by the rules, and not everybody is required to play by the rules. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thu, 01 Mar 2012 15:59:14 -0500, James Knott wrote:

Jim Henderson wrote:

...

I spent 15 years working in corporate IT environments as a systems engineer, with company sizes ranging from< 200 employees to> 250,000 employees.

Just because employees can be disciplined for violating IT policy doesn't mean (a) that they don't work around security measures put in place, or (b) that such discipline actually happens, even though it's a possibility.

So, your solution to a problem created by new openSUSE policy is for an employee to violate an employers policy, if they are able to? Maybe this is something that should be fixed at the source and make this sort of thing optional so that those who need it have it, but those who don't need it don't have it keeping them from doing their work.

Um, no, that's not at all what I said. Please try to avoid putting words in my mouth - I'm fully capable of speaking for myself. What I'm saying is that different people have different requirements based on what their use case is for the software. Some people need restrictive policies because they're in higher security environments. Some people need more relaxed policies because they're (a) not in a corporate environment, and/or (b) they have made a policy decision to not require such tight security. As is their right. I'm also saying that anyone who thinks that not knowing a root password is going to prevent people from elevating their privileges doesn't understand the requirements of physical security or how easy it is to elevate privileges when you have physical access to a system (regardless of what operating system you have). Saying "that's what corporate IT policies are for" is like saying "we have laws against theft, so now we never need to worry about people stealing things." I'm saying that to believe that is quite naive.

Anyone who agrees with the current policy of requiring root to enable WiFi connections is unbelievably clueless about the real world.

Not to put too fine a point on it, James, but this is complete nonsense. You're assuming that in the "real world" everyone has the exact same requirements for security. That is demonstrably not true. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thu, 01 Mar 2012 16:33:29 -0500, James Knott wrote:

Jim Henderson wrote:

...

What I'm saying is that different people have different requirements based on what their use case is for the software. Some people need restrictive policies because they're in higher security environments.

...

Not to put too fine a point on it, James, but this is complete nonsense. You're assuming that in the "real world" everyone has the exact same requirements for security. That is demonstrably not true.

As I have I said several times, it should be optional, at the dicretion of the admin or employer. However, that does not seem to be possible at the moment and that's what all the fuss is about.

Then it seems that we actually are in 'violent agreement' on the issue. :)

The developers decided they knew better than the users about what security is required to the point that it is currently useless in many business environements.

Agreed.

As I mentioned, I would not be able to do my work for that insurance company, if I'd been handed openSUSE 12.1

Indeed, many companies would have an issue with the settings currently in use. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Marcus Meissner wrote:

You can change the settings on your own machine (or your admin can).

Currently e.g. like:

- edit /etc/polkit-default-privs.local

And where is this documented? Your message was the first I'd ever heard of this. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, 02 Mar 2012 23:41:49 +0100, Marcus Meissner wrote:

On Fri, Mar 02, 2012 at 05:16:47PM -0500, James Knott wrote:

...

Marcus Meissner wrote:

...

You can change the settings on your own machine (or your admin can).

Currently e.g. like:

- edit /etc/polkit-default-privs.local

And where is this documented? Your message was the first I'd ever heard of this.

Well, I checked the manual ... http://doc.opensuse.org/documentation/html/openSUSE_114/opensuse- security/cha.security.policykit.html

start with 9.3.2. Modifying Configuration Files¶

It does not seem to be in the 12.1 manual, I have to query the doc department.

Where does one find a description of the different privilege name? I recall starting with the openSUSE docs, and then going to the policykit site, and at that time (at least), there wasn't anything that described what the actual privileges controlled. The list that you posted were all cups-related, that much I can tell - and some of them are pretty clear as to what they do, but if they're not actually in the file how would I know what privileges to add? Also, is there any documentation as to what the defaults are if the privilege is not found in the policy file? Again, something I looked for but couldn't find when I looked. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sun, Mar 04, 2012 at 08:37:15AM -0500, James Knott wrote:

Jim Henderson wrote:

...

Where does one find a description of the different privilege name?

I recall starting with the openSUSE docs, and then going to the policykit site, and at that time (at least), there wasn't anything that described what the actual privileges controlled.

The list that you posted were all cups-related, that much I can tell - and some of them are pretty clear as to what they do, but if they're not actually in the file how would I know what privileges to add?

Also, is there any documentation as to what the defaults are if the privilege is not found in the policy file? Again, something I looked for but couldn't find when I looked.

I guess we're just supposed to be able to guess all this. To put such restrictions on WiFi and printers, without proper documentation on how to change them is simply unbelievable.

a) There is no limitation to the WiFi configuration. My plain openSUSE 12.1 x64 with the KDE as included works well at many and very different configured locations. I'd like to see statements from lxde and Gnome users too. Please add the bugzilla IDs to your reply if it fails at the moment. b) The documentation. Well, if it is missing this has to solved as Marcus wrote earlier. And how is an issue like this tracked? Bugzilla. No, I'm not going to check for the bug ID. It's Sunday evening and I need to cook something.

Someone on the openSUSE team is clearly incompetent.

Please consider to be a bit more productive, positive, and friendly while communicating to your peers. This is a place where we intend to collaborate and to discuss and not to get hit below the belt. And this must clearly be independet of the age, gender, and even the employer. Your wording doesn't fit to the general and generic rules of human cooperation. To me it looks like I have to stress these rules apply to all statements on openSUSE lists too.

There is simply no excuse for this sort of thing.

You're right. For a wording like yours there is close to no excuse. Thanks, Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

On Sun, 04 Mar 2012 08:37:15 -0500 James Knott <james.knott@rogers.com> wrote:

... Someone on the openSUSE team is clearly incompetent. There is simply no excuse for this sort of thing.

If openSUSE team would be closed for contributions, as your comment implies, then there will be excuse for you not to participate in design of 12.1 at least as user giving feedback, but it is not closed. A lot of stuff is done by people that are not employee of SUSE. What you criticize now is actually in part your fault, as you had a chance to test before 12.1 hit the shelf. Now is late, but you can try with 12.2 (Factory). Disks are cheap this days and some 20GB for 12.2 will be barely noticeable on your hard disk. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* James Knott <james.knott@rogers.com> [03-05-12 08:14]:

Rajko M. wrote:

...

What you criticize now is actually in part your fault, as you had a chance to test before 12.1 hit the shelf. Now is late, but you can try with 12.2 (Factory). Disks are cheap this days and some 20GB for 12.2 will be barely noticeable on your hard disk.

Actually, I did have 12.1 running before "it hit the shelves" and, IIRC, I did mention this issue.

Then, you *can* provide the bug report number? -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/05/2012 09:27 PM, David C. Rankin wrote:

On 03/05/2012 08:12 AM, Patrick Shanahan wrote:

...

* James Knott<james.knott@rogers.com> [03-05-12 08:14]:

...

Rajko M. wrote:

...

What you criticize now is actually in part your fault, as you had a chance to test before 12.1 hit the shelf. Now is late, but you can try with 12.2 (Factory). Disks are cheap this days and some 20GB for 12.2 will be barely noticeable on your hard disk.

Actually, I did have 12.1 running before "it hit the shelves" and, IIRC, I did mention this issue.

Then, you *can* provide the bug report number?

Sheesh... I go work on Trinity for a bit and chaos ensues :)

All points well considered, wifi has always been a shortcoming of Linux desktops[1]. Partly due to the diversity of drivers for the various hardware and partly due to each distro taking somewhat of a different approach to scanning and configuring the various interfaces, but most importantly -- then changing the way they do it every 6 months.

I finally gave up attempting to follow the latest "gee whiz" way of configuring wireless. What works on gnome doesn't work on kde, what works with kde, doesn't work on fluxbox, etc.. For opensuse, it all boils down to a policy question "Are we going to allow non-root users to configure wireless access?"[2] If so, "how?", and "who's going to do it?"

Thankfully my laptops have used madwifi, so at least all I have needed to remember on opensuse is[3]:

su # wonder if a normal user would do this? iwlist wlan0 scan # this is a no.. iwconfig wlan0 mode Managed # ditto for the remainder iwconfig wlan0 essid "name" wpa_passphrase "name" "psk_up-to-64-Characters" \

...

...

/etc/wpa_supplicant/wpa_supplicant.conf kill -HUP $(pidof dhcpcd)

Why would anyone want to make this any easier than it already is? Certainly simple enough for any salesperson to remember and do on their own :)

Footnotes:

[1] yast doesn't help much from a desktop-user standpoint either. [2] Larry correctly noted that this was standard on KDE3, so reinventing the wheel this ain't... [3] curiously, this works well on most distros and with all WMs.

@David, You hit the nail on the head...only: your assumption that an average sales-person can remember the sequence let alone use the "su" command is flawed. The whole issue is that many users are just that: they use the system to produce something. They maybe proficient in video-editing and your not because you know more about the other things (just an example). Linus has installed the system, Lisa does not know nor care to know the root password. Lisa is a normal user, Linus is not. Point proven. The problem is not Linux, but the technicians building distros with a technical mind set. Where are the people who care about normal end-users who use the computer as a tool only. Frans. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Frans de Boer wrote: [big snip]

Where are the people who care about normal end-users who use the computer as a tool only.

+1. That is the one big question we need to worry about. -- Per Jessen, Zürich (1.8°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 06/03/12 19:21, Rasmus Plewe wrote:

On Tue, Mar 06, 2012 at 08:35:07AM +0100, Per Jessen wrote:

...

Frans de Boer wrote:

[big snip]

...

Where are the people who care about normal end-users who use the computer as a tool only. +1. That is the one big question we need to worry about. [pruned]

Lock down the server, but assume that a desktop is used by one person (at most a family, with natural social control) who needs to do what he wants. Like installing new software (hasn't been mentioned yet). Then, if you want to, add a "corporate desktop" which ist something in between. [pruned]

And I think that this is the crux of the problems - and a bane on the many discussions which occur here (and elsewhere). People are forgetting that openSUSE is the 'experimental' software which the "lab bunnies" are given for free to test, to report on the bugs et al, and have their patience and nerves stretched to the limit and all done with the ultimate aim of producing SUSE. The emphasis is not on the common, garden variety user at home but trying to make the software acceptable by corporations. But there doesn't seem to be the intermediary step of aiming at the ordinary user first and THEN altering things to suit the corporate world and environment. Unfortunately, there are many more people, the common home user, than there are corporations which is something that MS worked out many years ago - and prospered. And so has Apple for that matter. I don't see any articles about how many corporations are using Apples/MACs but we all hear how many Apple products are being bought by the punters in the streets. Just my $2 worth (that's what inflation is all about - 2c turns into $2......) BC -- The vulgar crowd always is taken by appearances, and the world consists chiefly of the vulgar. Niccolo Machiavelli -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tuesday, March 06, 2012 14:03:40 Per Jessen wrote:

Basil Chupin wrote:

...

People are forgetting that openSUSE is the 'experimental' software which the "lab bunnies" are given for free to test, to report on the bugs et al, and have their patience and nerves stretched to the limit and all done with the ultimate aim of producing SUSE.

Uhm, not quite:

http://lists.opensuse.org/opensuse/2011-11/msg01359.html

"No, we're not - anymore - the testing ground, openSUSE is upstream of SLES"

Thanks for citing me quickly. I was just going to refute Basil and state that openSUSE is a distribution on its own. Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wednesday, March 07, 2012 16:12:14 Basil Chupin wrote:

On 07/03/12 00:30, Andreas Jaeger wrote:

...

On Tuesday, March 06, 2012 14:03:40 Per Jessen wrote:

...

Basil Chupin wrote:

...

People are forgetting that openSUSE is the 'experimental' software which the "lab bunnies" are given for free to test, to report on the bugs et al, and have their patience and nerves stretched to the limit and all done with the ultimate aim of producing SUSE.

Uhm, not quite:

http://lists.opensuse.org/opensuse/2011-11/msg01359.html

"No, we're not - anymore - the testing ground, openSUSE is upstream of SLES"

Thanks for citing me quickly. I was just going to refute Basil and state that openSUSE is a distribution on its own.

Andreas

Thank you, Andreas, for your response.

I realise that openSUSE is a distribution on it own now - well at least since some recent time.

But then so are Ubuntu and Fedora and Mint and Debian and Red Hat and......all are separate distributions :-) .

However, one cannot help noting the following entry in Wikipedia:

QUOTE

On April 27, 2011 Attachmate completed its acquisition of Novell. Attachmate split Novell into two autonomous business units, Novell and SUSE. Attachmate has no plans to change the relationship between SUSE (formerly Novell) and the openSUSE project.

UNQUOTE

The question now needs to be asked and clarified: where does SLES fit in - is it in the openSUSE "camp" or in the Novell/SUSE "camp"?

There is no Novell/SUSE anymore and thus no Novell/SUSE camp ;) SUSE is the main sponsor of the openSUSE project. SUSE Linux Enterprise is using openSUSE as it's upstream. Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 07/03/12 00:03, Per Jessen wrote:

Basil Chupin wrote:

...

People are forgetting that openSUSE is the 'experimental' software which the "lab bunnies" are given for free to test, to report on the bugs et al, and have their patience and nerves stretched to the limit and all done with the ultimate aim of producing SUSE. Uhm, not quite:

http://lists.opensuse.org/opensuse/2011-11/msg01359.html

"No, we're not - anymore - the testing ground, openSUSE is upstream of SLES"

Thanks, Per, for the response and thanks for that link. If I may, I will quote what is in that link which was a reply to something which Carlos posted: QUOTE On 11/24/2011 02:37 AM, Carlos E. R. wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2011-11-23 at 17:51 +0100, Per Jessen wrote: It's apples and oranges - that's why your frame of reference doesn't apply (or isn't really useful). However, if openSUSE doesn't work, neither will SLES later on. We are their testing ground. And if the "unvoluntary testers" get too pissed, then they lose their testing ground. No, we're not - anymore - the testing ground, openSUSE is upstream of SLES, Andreas UNQUOTE Without being pedantic, but what the above states is that "openSUSE is upstream of SLES". Nothing more and nothing less. KDE is "upstream" and it is used in openSUSE (with "modifications" to suit openSUSE). So is the kernel. So is Gnome. So is LibreOffice. And the list goes on. In each of the cases I just mentioned the "upstream" applications are being made available to a Linux distros, just like openSUSE, to be tested out by their users to identify any bugs et al. openSUSE users reporting some bug in, say, KDE, and which has been confirmed as a bug, are told that the "fix" has to go *"upstream"* before it can be implemented. (You get the picture.) Having a statement which states that "..openSUSE is upstream of SLES" does not mean that whatever openSUSE comes up re improvements/bug reports/bug fixes fixes will not be used as input to SLES nor does it mean that SLES has now its own paid staff of developers who work on improving/whatever SLES and who *totally* pay no attention to whatever openSUSE users are saying re bugs/ improvements/etc. (Just as an aside, what is the URL where any bugs are reported? Oh, sorry - and I mean it - but I just did a search and found that the place to report bugs is: http://bugzilla.novell.com.) I am aware that since Attachmate (and partners) bought Novell, openSUSE and the 'commercial' side of SUSE have been split and that now there is yet to be created an official and legal entity not-for-profit organisation Foundation called something like 'opensuse.org'. But I have not yet read anything which states that whatever openSUSE users comment on or report as bugs/improvements to openSUSE will not be used as input to SLES because SLES is totally ignoring such information and going its own way. Which, by the way, would be an absolutely unrealistic and moronic scenario for somebody with a half a brain to do. If I am wrong in my conclusions and statements then please point me to the appropriate references/sources which will be at variance with I wrote - please! BC -- The vulgar crowd always is taken by appearances, and the world consists chiefly of the vulgar. Niccolo Machiavelli -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, 07 Mar 2012 00:05:02 -0500, Brian K. White wrote:

On 3/5/2012 12:39 AM, Rajko M. wrote:

...

What you criticize now is actually in part your fault, as you had a chance to test before 12.1 hit the shelf. Now is late, but you can try with 12.2 (Factory). Disks are cheap this days and some 20GB for 12.2 will be barely noticeable on your hard disk.

Way to transfer the blame from people who made a change to people who suffered the effects of it.

OK, guys? Neither of these comments is particularly constructive or helpful in moving the conversation forward and actually resolving the problem. Can we get away from blamestorming on this and actually get to the point of figuring out how to actually FIX the problem? Thanks, Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, Mar 2, 2012 at 2:20 PM, Jim Henderson <hendersj@gmail.com> wrote:

On Fri, 02 Mar 2012 23:03:27 +0100, Marcus Meissner wrote:

...

On Thu, Mar 01, 2012 at 04:33:29PM -0500, James Knott wrote:

...

Jim Henderson wrote: As I have I said several times, it should be optional, at the dicretion of the admin or employer.  However, that does not seem to be possible at the moment and that's what all the fuss is about.  The developers decided they knew better than the users about what security is required to the point that it is currently useless in many business environements.

The security team decided on a good standard policy.

One might argue that the security team decided on a default "secure" policy, which might be a bit too restrictive for some people.

...

No other developers were found that worked on a good design that is both usable and secure.

It's a matter of convenience - if someone wants to be less secure, the can of course set the system up to be that way, but they bear the consequences of it.

...

You can change the settings on your own machine (or your admin can).

Currently e.g. like:

- edit /etc/polkit-default-privs.local

add the lines: org.opensuse.cupspkhelper.mechanism.printer-set-default auth_admin_keep:auth_admin_keep:yes org.opensuse.cupspkhelper.mechanism.printer-enable auth_admin_keep:auth_admin_keep:yes org.opensuse.cupspkhelper.mechanism.printer-local-edit auth_admin_keep:auth_admin_keep:yes org.opensuse.cupspkhelper.mechanism.printer-remote-edit auth_admin_keep:auth_admin_keep:yes org.opensuse.cupspkhelper.mechanism.class-edit auth_admin_keep:auth_admin_keep:yes org.opensuse.cupspkhelper.mechanism.server-settings auth_admin_keep:auth_admin_keep:yes org.opensuse.cupspkhelper.mechanism.printeraddremove auth_admin_keep:auth_admin_keep:yes org.opensuse.cupspkhelper.mechanism.job-edit auth_admin_keep:auth_admin_keep:yes org.opensuse.cupspkhelper.mechanism.job-not-owned-edit auth_admin_keep:auth_admin_keep:yes org.opensuse.cupspkhelper.mechanism.devices-get auth_admin_keep:auth_admin_keep:yes org.opensuse.cupspkhelper.mechanism.all-edit auth_admin_keep:auth_admin_keep:yes

(the "yes" to the third argument gives the active user full rights to all these calls.)

That's a pretty ugly way to have to modify the policy, and the values aren't (as near as I've been able to tell) very well documented anywhere.

Jim --  Jim Henderson  Please keep on-topic replies on the list so everyone benefits

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

I would still prefer a graphical way of doing this in yast and a security selection in the installer with a low, medium and high security profile. -- ____________ Steven L Hess ARS KC6KGE DM05gd22 Skype user flamebait Cell 661 487 0357 (Facetime) Google Voice 661 769 6201 openSUSE Linux 12.1 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Roger Oberholtzer wrote:

...

With Linux, give anyone a grub menu and nothing else, and it's trivial to

...

get to a root prompt and change the root password. In a corporate world, the trick then would be to set the root password back after this so the IT police don't know you did it...

The trick to resetting the password is knowing what it was originally. It's easy enough to change the password to something new, but restoring the original? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, Mar 02, 2012 at 07:47:50AM -0500, James Knott wrote:

Roger Oberholtzer wrote:

...

...

With Linux, give anyone a grub menu and nothing else, and it's trivial to

...

get to a root prompt and change the root password. In a corporate world, the trick then would be to set the root password back after this so the IT police don't know you did it...

The trick to resetting the password is knowing what it was originally. It's easy enough to change the password to something new, but restoring the original?

a) boot with init=/bin/bash b) mv /etc/shadow /etc/shadow.orig && cp -a /etc/shadow.orig /etc/shadow c) passwd As soon as you finished your work you move /etc/shadow.orig back. The majority will not notice this. As they have not protected the boot loader. As soon as the boot loader ist password protected it gets only a bit more tricky. Remove the harddisk and manipulate all from inside a different host. In this case you'll very likely not be able to boot from an external media. Well, you can protect more and more and at the end all these evil red hairy monters will find a way. ;) The only items very well protected against use are printers. ;) Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

On 03/02/2012 08:24 AM, James Knott pecked at the keyboard and wrote:

Lars Müller wrote:

...

And why should people have to do this to work around an incredibly STOOPID decision?

Isn't that what the checkbox in network device is for, allowing "non-root user device control"? -- Ken Schneider SuSe since Version 5.2, June 1998

On 3/2/2012 7:47 AM, James Knott wrote:

Roger Oberholtzer wrote:

...

...

With Linux, give anyone a grub menu and nothing else, and it's trivial to

...

get to a root prompt and change the root password. In a corporate world, the trick then would be to set the root password back after this so the IT police don't know you did it...

The trick to resetting the password is knowing what it was originally. It's easy enough to change the password to something new, but restoring the original?

You don't have to know what it was to save & then restore it. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Hello, On Mar 1 14:27 James Knott wrote (excerpt):

Johannes Meixner wrote:

...

If the use case is "printer setup on my own machine", I think - but I am not at all a security expert - it should be an acceptable solution when the normal user's password and the root password are the same so that from the user's point of view there is just one password i.e. THE password.

Not in the corporate world. Business employees generally do not get root or admin access to their computers.

Either I do not understand what you write or you do not understand what I wrote. I wrote "own machine" with the meaning of "owner" not with the meaning of "who works on it". Guess what: I know an example in the corporate world where particular employees have access to the computers on which they do their work in the same way as if the employee was the owner of the computer (regardless that the actual owner is the company). Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen wrote:

Johannes Meixner wrote:

...

...

Guess what: I know an example in the corporate world where particular employees have access to the computers on which they do their work in the same way as if the employee was the owner of the computer (regardless that the actual owner is the company). The exception that proves the rule?

I have worked at one company where I had admin privileges, but that was an exception. When doing support at IBM, I had my one password for my own computer and a separate admin password for doing work on other user's computers. On my own computers, I have separate accounts for me as a user and for root/admin with different passwords. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, Mar 02, 2012 at 07:55:58AM -0500, James Knott wrote:

Johannes Meixner wrote:

...

...

Not in the corporate world. Business employees generally do not get root or admin access to their computers.

Either I do not understand what you write or you do not understand what I wrote.

I wrote "own machine" with the meaning of "owner" not with the meaning of "who works on it".

I guess you're missing the theme of the thread. "Own machine" is not the issue, where this barely qualifies as annoying. My comments, along with Linus and others is for systems that are used by those who do not have the root password. This could be Linus's kids or employees of a company. Both have legitimate reasons for using WiFi or printers at various locations and are prevented from doing so in openSUSE 12.1. I mentioned a project I'm working on for an insurance company. If I had 12.1 and no root password, I could not have used the WiFi at hotels I've stayed at nor could I connect to local printers, as I need to, in order to do my work. There is absolutely no excuse for this level of stupidity or arrogance on the part of the openSUSE developers. It is flat out wrong!

OpenSUSE is a community project and you're welcome as a member to find and/or provide a manageable and secure solution for both a one user or shared users systems as well as for real multi user systems. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Roger Oberholtzer <roger@opq.se> [03-01-12 02:40]:

On Thu, 2012-03-01 at 00:17 +0100, jdd wrote:

...

read man sudoer

See my earlier response to Patrick on this. sudo is all-or-nothing for the program. You cannot restrict a single program to a subset of root permissions. You get them all.

This is *not* so. Have you looked at /etc/sudoers? <quote> ## ## User alias specification ## ## Groups of users. These may consist of user names, uids, Unix groups, ## or netgroups. # User_Alias ADMINS = millert, dowdy, mikef ## ## Cmnd alias specification ## ## Groups of commands. Often used to group related commands together. # Cmnd_Alias PROCESSES = /usr/bin/nice, /bin/kill, /usr/bin/renice, \ # /usr/bin/pkill, /usr/bin/top ## ## Uncomment to enable logging of a command's output, except for ## sudoreplay and reboot. Use sudoreplay to play back logged sessions. # Defaults log_output # Defaults!/usr/bin/sudoreplay !log_output # Defaults!/sbin/reboot !log_output ## In the default (unconfigured) configuration, sudo asks for the root ## password. ## This allows use of an ordinary user account for administration of a ## freshly ## installed system. When configuring sudo, delete the two ## following lines: Defaults targetpw # ask for the password of the target user i.e. root ALL ALL=(ALL) ALL # WARNING! Only use this together with 'Defaults targetpw'! </quote> from the man page DESCRIPTION sudo allows a permitted user to execute a command as the superuser or another user, as specified by the security policy. The real and effective uid and gid are set to match those of the target user, as specified in the password database, and the group vector is initialized based on the group database (unless the -P option was specified). and users can be added to groups which have permissions to do *specific* things, ie: wheel, wwwrun -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org