Thanks for recommendation, and if I will find something on theme I will show you it.

sed -i 's/exit 1/#exit 1/' soma

Thanks, I already made that manually.

BUT, the change will be lost in the first update...

BTW, SOMA works fine as root.

And a last suggestion, this time aesthetically: how about to clear the console on exit?

Can do. I'll add it next update.

Thanks!

And how about instead of an unceremonious exit for the root user, to use an confirmation dialog like "You are sure you want to do that?"

Leave to the user to accept the consequences.

Optional though.

Ah. When I am logged into my VM I am using Terminator to ssh from, so that makes a difference I expect.

But I did test uxterm and it all looked ok.

Yep, showing to user at least a confirmation dialog is just about giving him the ability to chose, without babysitting him.

And after all, now after I read the SOMA's source code (as it is a script), I think that there are no security issues other than the ones introduced eventually by MPlayer itself.

BUT, its graphical interface, the GMPlayer can run well as root, with no warnings and bells, then if the MPlayer developers themselves are not so preoccupied by running their software as root, and MPlayer is officially shipped by Slackware, how about to leave the responsibility about the MPlayer issues just to those in measure and with interests about MPlayer security?

That's the delegation of the responsibility.

Long story short, what SOMA do, the user can do under root also with the pure MPlayer, the GMPlayer, or even clients like SMPlayer, for example.

So, the SOMA will introduce no additional security when it commit suicide as root even the user does not edit its forced exit.

I see your point. I'm just worried that something hideous will go wrong. Mistakes have been known to have been made in software before. See the purge_local function and think what fun could be had if the directories were -z or / or something.

I'm not thinking of a confirmation really for the clear screen, more a config option. Set by checkbox in the options menu.

1 members found this post helpful.

I understand your position, but I think that nothing bad will/could happen, if you ensure that the "to be deleted" files would live in folders precisely named ".soma/genres" or ".soma/themes", even by mistake the SOMA looks to delete them directly from "/.soma/genres" or "/.soma/themes", which usually should not exists.

IF I will be worried about that particular problem, I would strongly ensure those path names conditions I said. I done many times in the past those things, under PHP, BTW...

Why do you want to run it as root anyway? Just stop!

1 members found this post helpful.

Sorry if I made you angry, was just an theoretical POV and comments about your own app.

Or, you do not like someone to discuss its design?

Haha... you could add some option to bypass your root check. That way it's a nice reminder for those who may run as root without knowing why it's bad, but allows those who are aware of the consequences to be able to bypass it if needed/desired.

2 members found this post helpful.

dive, soma doesn't work with 13.37. What versions of Slackware do you support?

I've only tested it on 14.2 and -current. I don't have a 13.37 box to test with.