I had a look, but couldn't find any bugs to indicate it was set 644 for a reason, so I'll pass it to Dan for judgment, and set it to a target of the next release.

File permissions changes have caused unforseen problems in the past, and if this change causes such a problem, I'd rather not have it in 6.5.1.

Concerned users can use your provided workaround, thanks!

Aren't passwords encrypted in the conf file?  If not, shouldn't they be?

(In reply to comment #2)
> Aren't passwords encrypted in the conf file?  If not, shouldn't they be?
> 

The password used by SS itself (not plugins) is encoded (not sure about encrypted)... it looks a simple Base64 thing, but I haven't tested it. The XMRadio plug-in stores the XMRadio-site userid/password in plain text.

I don't know what other plug-ins requiring passwods do.

Is there anything wrongwith SS setting up the config file to be not world-readble? Then if plugin authors decide notto encrypt passwords, they're still reasonable safe.

Does the ss API provide an encrypt/decrypt call so plugin authors wouldn't have to write their own?

Fletch: can you take a look at this?

This is easy enough to do in the RPM if that's what you want, but that won't address the issue on other platforms.  My suggestion is to close this as WONTFIX and open a new bug that passwords shouldn't be saved in prefs as plain text.  The Sirius Radio plugin uses Digest::MD5.  Let me know if you still want this changed in the RPM.

(In reply to comment #5)


Since it is easy to correct the world-readable part in the RPM, I suggest doing that even though it does not solve the problem on all platforms. I think it is worth doing because it is the "right thing" and takes advantage of some platforms' architecture to improve security/"privacy".

I also agree that the password should be encoded/encrypted in a non-trivial way so that even if somebody does compromise the machine, the password is protected.

The password is "only" for a radio service plugin... but that's not the point. "Best practices" would grant permission on a "needs to have" basis. Since there is no compelling reason for any program/process other than the file owner to use that file, the permission should reflect that.

Rather than closing this as WONTFIX, I recommend fixing the RPM as you suggest, and in addition changing the password to be kept encrypted.

If you DO close this as WONTFIX, please add a comment linking to the new bug.

On a related note: I have not done any work writing plugins for SlimServer... is there an API to get/set values from/in the configuration file? That is, is it up to the plug-in writer to encrypt things if needed? If there isn't one already, there should be such an API so storing of "sensitive" information can be protected in a consistent manner. That requirement, if not currently available, should be a new Bugzilla report. :-)

(In reply to comment #6)
> "Best practices" would grant permission on a "needs to have" basis. Since there
> is no compelling reason for any program/process other than the file owner to
> use that file, the permission should reflect that.

I think this is an exaggeration.  On any Linux system, probably 90% of the files in /etc are world readable.  IMO, that simplifies admin and debugging and encourages administrators to safely spend less time logged in as root.

> On a related note: I have not done any work writing plugins for SlimServer...
> is there an API to get/set values from/in the configuration file? That is, is
> it up to the plug-in writer to encrypt things if needed? If there isn't one
> already, there should be such an API so storing of "sensitive" information can
> be protected in a consistent manner. That requirement, if not currently
> available, should be a new Bugzilla report. :-)

FYI, in SC7, plugins do not use the main prefs file.  Each plugin has it's own prefs file.  AFAIK, there is no standard way for a plugin to encrypt a password.  Maybe that could be part of the other bug I suggested.

Anyway, I'll wait for Dean to decide what to do...
 

(In reply to comment #7)

> I think this is an exaggeration.  On any Linux system, probably 90% of the
> files in /etc are world readable.  IMO, that simplifies admin and debugging and
> encourages administrators to safely spend less time logged in as root.

I don't know what other admins do, but I do that sort of maint from my slimserver ID, not root.
There's no reason to be logged in as root for that sort of thing.
 
> FYI, in SC7, plugins do not use the main prefs file.  Each plugin has it's own
> prefs file.  AFAIK, there is no standard way for a plugin to encrypt a
> password.  Maybe that could be part of the other bug I suggested.

Yes, that sounds like a good idea. :-)

> Anyway, I'll wait for Dean to decide what to do...

Yes... no worries. Thanks for the discussion.
Cheers.

FYI, I took a quick look at this and a fix is more than just an RPM change.  Something in the code (not sure where) seems to change the mode of server.prefs to 644 whenever a change is written.

In response to Chris's email regarding open 7.0 bugs, here's a summary of the status of this bug:

1) I still think that the best course of action is to not fix this bug and instead have all passwords be encrypted in the prefs files.
2) If you still want to make the change requested here, the RPM part of the fix is trivial but I need help from Andy or someone to understand why the server.prefs file is always written with mode 644 regardless of how the original file is created with by the RPM.

Either way, this has been this way for a long time and can probably be deferred to post 7.0 if necessary.

Will reevaluate post-7.0

(In reply to comment #10)
> In response to Chris's email regarding open 7.0 bugs, here's a summary of the
> status of this bug:
> 
> 1) I still think that the best course of action is to not fix this bug and
> instead have all passwords be encrypted in the prefs files.
> 2) If you still want to make the change requested here, the RPM part of the fix
> is trivial but I need help from Andy or someone to understand why the
> server.prefs file is always written with mode 644 regardless of how the
> original file is created with by the RPM.
> 
> Either way, this has been this way for a long time and can probably be deferred
> to post 7.0 if necessary.

OK... I'm older and wiser ... well, I'm older now... :-)

I concur on points 1 and 2 above... storing the password as an MD5 digest (or something similar) and not changing file permission is good enough.

I haven't checked... we're up to 7.3.3 or something like that... is this still an outstanding issue?

Cheers,
Don