Run VLC using root account
 

Hi Guys

I m facing a problem while run vlc using root account , when i run vlc nothing is happened and the following message is display

VLC is not supposed to be run as root. Sorry.
If you need to use real-time priorities and/or privileged TCP ports
you can use vlc-wrapper (make sure it is Set-UID root first and
cannot be run by non-trusted users first).

so i want to know is there is any trick to run vlc using root account

all reply is appreciated
thanks in advance
Best Regard
Ashish Sood

The only way around this which I'm familiar with is recompiling. Pass the --enable-run-as-root flag to ./configure and vlc should be able to run as root.

But i does not install VLC using tarball, i install it using rpm and i m using fedora 10 so i there is any way to run vlc as root.

Thanks For reply Maligree

There is a reason why it won't run in a root account.
Why do you want to run it in root account?
Just run it as user.

Why do you need this? Root account is for system maintenance only, not for everyday use.

guys i actually use to login using root account instead non privelage user account , that why i want to know .

Thanks for reply

Well, you already got your answer in the second post. You'll have to remove your existing package and install vlc from source with the appropriate parameters.

Please don't go onto the internet as root, as such irresponsible behaviour puts the rest of us at risk.

Regards,

If you're going to sign in as root all the time you might as well go back to windows.

Everywhere i'v read about this topic theres always a bunch of people blabbering on about privaleges. This person got his answer, so why all the crap about what he should and should not do, after all its his machine, isn't linux meant to be about freedom and choice , im sure he has already acknowledged the risks of using his machine with the root account and doesn't want it most of this crap.

People should post like maligree, with the actual answer!

Sorry to post to a partly old thread, but this is a good solution to this problem (and no, I'm not spamming the forums): http://www.codefaction.net/fixed/
It has the modified VLC source code to strip the checking for root... it has the binary precompiled (i386 arch) and a patch if you want to apply it to the vlc developers code directly. Thanks.

Hi, this is the second time u have said this, could u please elaborate, simply pls

-_- come to the dark side, run as root, you will find that you don't have to type sudo in front of anything you type, there will be no locks on the icons on your desktop, and you will notice that you have grown a full beard.

putting the rest of you at risk is a risk I am willing to take ;)

---------------------------------
also:

before doing these steps you may have to purge your existing vlc installation (apt-get purge vlc)

wget -c http://download.videolan.org/pub/vid...0.9.9a.tar.bz2
tar -xvf vlc-0.9.9a.tar.bz2
cd vlc-0.9.9a
apt-get build-dep vlc
./configure --enable-run-as-root
make
make install
------------------------------
start it from command line, (simply type vlc or /usr/local/bin/vlc) it may give you an error about libvlc.so, if it does run:

apt-get install libvlc-dev libvlc2

and just like magic, vlc is workings in root. compiling takes forever though -_- ...

Much thanks for this post. If I wanted an operating system to hold my hand and remind me of what is a potential security problem, I would have gotten Windows Vista.

Logically speaking, Linux should warn you of hazards whenever you plug in your ethernet cable.

Plugging into teh intarwebs puts the rest of us at risk. Why isn't there a warning against going online as root?

If you are running KDE, the simple thing to do would be to...

1) Click your KDE Start Menu.
2) Applications/Multimedia/Video folder (If running PClinux, Kick off menu)
3) Right click VLC and "edit item" (KDE Menu Editor)
4) Second last option on right side (check box "Run as different user")
5) Enter a profile user name on your computer other then root.
6) Exit and save changes.


I'm no computer linux guru, but this was easy to do and it WORKS!

more on running vlc as root
 

Hi All

Well this works but no sound...
"If you are running KDE, the simple thing to do would be to...

1) Click your KDE Start Menu.
2) Applications/Multimedia/Video folder (If running PClinux, Kick off menu)
3) Right click VLC and "edit item" (KDE Menu Editor)
4) Second last option on right side (check box "Run as different user")
5) Enter a profile user name on your computer other then root.
6) Exit and save changes."

So the permissions of the lowly user are not good enough to have access to the sound system.

So:
[as root - open terminal window]
cd /dev
chmod 666 dsp

vlc now has sound when run as a 'user'.

I know this thread is over 2 years old, but I am posting because it is the first thread that comes up on a google search for "run vlc player as root".

I just wanted to post a simpler way to run vlc as root without recompiling the source. You can open up the binary for ubunt it is found in /usr/bin/vlc, then find the string that matches "geteuid" and replace it with "getppid".

It's simple, quick, fast and works on the original binary, so there should be no issues.

It also works with various other programs.

Saying
completely ignores the fact the developers added that warning and restriction for good reason.

As said before: root is for system maintenance.

Yes, there are plenty of tools running session as root.

;)

God forbid if someone wants to listen to music during system maintenance, but anyway, as has been said, why are people concerned when adults who understand the potential risks want to do it? There is no law against it. There are people who still want to accept unverified certificates in their browser regardless of the risk, should it be up to the browser to stop them??

There is no danger of liability on the developers as the issues are well known, why must people keep warning a person who already knows the warning. Just think of those people as being unwise or downright stupid and keep it moving. You can say things a million times but not everyone is going to choose to run their distro as you do.

I think using vlc-wrapper would do.

If you are running your GUI as root for system maintenance you are doing something wrong. There is absolutely no reason to run the GUI as root ever. If you need to run a GUI program as root there are several ways to do that without elevating the whole GUI to root. For example programs like gksu(do), kdesu(do) or sux.

Because most of the time those adults do not understand the potential risks. Where do you draw the line? If you are doing system maintenance with your GUI running as root, do you start your browser, may be to search for documentation or a specific error message? If the answer to that is yes than your system is already potentially compromised.

I couldn't care less about your system, but what I care about are my systems, those systems that are brute-force attacked, DDOSed or simply receive spam mails from compromised systems. With your behavior you are potentially harming our machines, that is why we have to repeat this over and over again. Did you consider that as part of the risks you claim to have understood?

I couldn't care less about your system, but you should, because your system may not only harm our machines, it may harm you directly, in person. Explain to the police that the copyrighted material hosted on your machines does not come from you. Or the snuff videos, childporn or whatever illegal content you may think of. Did you consider that as part of the risks you claim to have understood?

The answer is the same, because most of the time that person only thinks to be aware of the issues, without seeing the whole context.

No, I don't think of those people as being unwise or stupid. Because in almost any case they aren't. In almost any case they are either uninformed (which can be easily corrected) or downright lazy. But laziness is no excuse at all.

Of course not, why should they. But it is the same as in sports: No athlete has the exact same style as the next. But nonetheless will all athletes behave in the widely accepted way when it comes to their own and others security in that sport.

Sorry TobiSGD but one with experience running the whole GUI as root would disagree and I'm aware of all that you mean. The only difference is probably just the machine in concern. For normal user desktops running your GUI as root or just a normal user is not really different when it comes to security risks. For capable users, things like 'su' and 'sudo' are just things that slows them down. It's not about being lazy or not. It's just about being practical.

May I just ask what exactly it is that you do that you have to do that needs the whole GUI running as root?

This threads almost immediately had 3 or 4 people screaming about the dangers and risks IN DETAIL of running as root. How many more posts on the same thread is going to inform that person any more?? That person has accepted those risks. People accept the risks of eating trans-fat and accept the risks of smoking, none of those people at this point in our society can be said not to understand those risks. At what point do you want to become a nanny state for computer users?

People should know to have data-backups, make restore points, not use the same passwords over and over again. Basic security and data protection issues. At what point do we say they take the responsibility? Whether people choose to do things out of laziness or lack of will-power, there comes a point that you give them the responsibility.

These programs themselves tell the users about the dangers and try to prevent them from running as root, just like packs of cigarettes tell you the dangers of cancer, but it seems like there are some people who want to take their outrage at the lack of good sense and make some type of prohibition and become the Mayor Bloomberg of linux use. I get it, some people are offended that such people would take such risks, but once you know they have been informed, then the rest is on them. It is their computers, their data, their computing life, let them live it.

Seems that you didn't get the point. As stated before, I don't care about their computers, their data, their computing live. I care about my computers, my data and my computing life. And compromised machines will evidently have an impact on that. As long as the specific user does not grasp that he is still uninformed and needs to be educated for their own and our good.

We don't allow drunk drivers, not because they may damage their own health or their own cars, but because they may harm others with that behavior. So why should we allow people to pose a risk on us in other areas? That doesn't really make sense.

Just this year when I had a new installation of Gentoo I found myself making a decision to no longer run as a superuser in GUI, although I still have the account ready to run as GUI when it's needed. The last time I ran as root GUI was when I used gparted. I'd probably do that again if I need to do multiple tasks which would require superuser access. Packages like vlc restricting themselves to run as root was probably the biggest reason why I no longer run in GUI as superuser by default.

There actually wasn't really a reason or specific sets of tasks that I chose to run as root by default. I got used to running systems with full control and I am in control of my system so why would I have to be careful then. The first GUI system I had - Slackware with GUI 9.1 (KDE), I always ran as root and never had a problem with it.

Knowing myself I do often encounter tasks which needs superuser accesses. Well I don't really want to be specific in saying what they are. One thing is when I'm still building my system at least after a lightweight desktop like XFCE4 is already running. Running as root in GUI is also better if you're doing low-level development/debugging tasks. I also choose my favorite editor sometimes when editing root-owned files.

In general I just didn't want to bother myself with unnecessary efforts of elevating tasks with su or sudo every time you needed them.

P.S. I'm not sure how a GUI app could run with sudo. I don't like the idea. I believe it would cause to allocate more memory for the sake of the app's runtime enironment. I haven't explored much that yet but so far I see it as a hack.

This actually looks like laziness. As I stated before: Use kdesu(do), gksu(do) or sux for that.
What you are saying here comes basically down to: I base the decisions regarding the security of my system(s) on a personal opinion that is based on believes. I haven't researched how the facts are, but nonetheless have an opinion on it.

Sorry I have to say that, but if you were working for me as a system admin with this attitude you wouldn't work for me anymore.

Ok it's up to you how you would look at it.
Sorry I believe my knowledge about the matter is enough already. As a concept for security the GUI kernel would have to set another environment to serve the other app which is running as a new user. Other method than that and would be a hack.
I wouldn't work for a conservative employer like you either.

Anyhow this just boils down as a matter of personal philosophy but you saying that:
Is absolutely wrong for me.

You are the first person ever that called me conservative. But if insisting on basic security principles is nowadays called conservative then may be I should be called conservative.

May I quote yourself?
You yourself state that you have not explored that topic, but now you believe that you have enough knowledge about it.

Actually no, basic security principles are not a matter of philosophy, they are a matter of fact.

Luckily you are a very small percentage with this habits. Otherwise the Linux world would be as simple to target for malware developers as the Windows world was with XP.

Just for educational purpose, for anyone who is interested in what I am speaking about in my conservativeness ;) : http://en.wikipedia.org/wiki/Princip...east_privilege

Basic principles are basic, and standard/procedure-oriented. And even if you quote some popular principles it won't be enough. Time and accessibility would always be sacrificed.
I think you mean the details and not the choice of application.
Not enough to give factual details but enough for me to stand what I believe. Not that I'm really going far as to really prove it. I already gave the concept. Prove it wrong if you want to prove me wrong.

Yeah right. Can you even tell how a malware would propagate that you could compare it to XP?

Like the way of chroot jailing and SELinux as I applied it to servers yes. Certainly it's already known widely. But security is not all about limiting access. Some methods are even more effective without sacrificing accessibility. Those you refer to are just basics.

The main reason for the widespread deployment of malware on Windows XP was that the default user automatically had administrator priveleges. Any exploit for software facing the net (mail clients, browsers, chat clients, ...) had not to circumvent any restrictions to install and run itself on the machine. Why would you think that this is different on a Linux machine running the software exposed to the net as root?

So your concept, although you won't prove it, is good enough to compete with the concepts designed and proven by generations of security experts, although you admit that you have not researched this topic very deeply? That is interesting.
By the way, I don't have to prove you wrong, usually the burden of proof is on the one who makes the claims.

On Linux with root user running a vulnerable client of course it would be breached, but how would a breached client be able to breach another one? Can that affect a significant amount of distros which are also running as root that you could say that the effect is widespread? Of course you wouldn't think services are running as root as well.
It's not that I'm thinking that they're doing another method. Or do you mean they came up with a better solution? The two major possible designs are just obvious. One is separation by environment. Second is micro-control in every API service. And the latter was the one one I'm referring to as a hack.

That is why I said that it is luck that only a small percentage of users have your usage habits. Otherwise we would have the same situation as XP.

Most are not, especially those that are offered to the net.

Do I understand that right? You prefer a totally insecure system to one that uses a method you consider as hack?

Again, users in Linux running as root is not enough to give devastating damages as much as what happened to XP.What I mean is that even if you favor running GUI as root, it's not necessary that services would follow as well.
It's not always an insecure system for capable users with control. Insecurity is not even a question sometimes. The better way to put it is that I would prefer taking controlled and not-really-applicable risks than using those methods if I am to gain easier and less expensive accessibility.

The thing is that there are situations where being careful is not necessary, and there are also situations where being hacked as a normal user is just as damaging as being hacked as root.

No, you would also need the developers to write exploits for it. which wouldn't take very long if all people would use your security scheme.

Services are usually not started by the GUI, so of course they would not be run as root because you choose to run the GUI with that user. But any application that you start from within the GUI will run as root in that case. You don't tell me that if you do admin tasks and have to look up some documentation on the net first logout of the root GUI, do your researches with a browser form an unprivileged account and then login back as root, just to finf out that the approach does not work and you have to do that procedure again?
Or do you start the browser as unprivileged user using one of the "hacks"?

True, but if your normal user and root are one and the same this doesn't apply anymore, just because all situations are as damaging as being hacked as root. Just because there is the possibility that someone breaks a locked door the logical conclusion is not to don't use locks.

Still after they had written those it still won't be enough to give that much damage. You're missing a crucial factor which can never appear in Linux as compared to XP. At least it can never be that close as how things are arranged.
Not always especially on services.
Do you really think it's necessary to not run the browser as root? Are all source sites that dangerous, and if there are exploitive ones would they be even always effective against your own client? What's the significance of it if your browser cannot or will not be breached at all?
Just shows how closed your perception about the matter is that you wouldn't even think of other possibilities other than the obvious.If I am to make a reply I would answer the same answer again. I guess that concludes the difference of our beliefs. Again it's about the other benefits one would choose over unnecessary insecurity and indeed there are reasons as to use GUI as root compared to what you stated that I find absolutely conservative.

Instead of making vague statements, just come out with it directly: Why do you think that an successful attack against root on a Linux system would be less harmful or more restricted than a successful attack on a XP user with admin privileges.

As I stated before, services usually are not started from the GUI itself. I am talking about the applications that are running within the GUI, browser, chat-clent, VLC, whatever.

No, i don't believe that. It is a fact that it exposes security risks to do that. This is a technical matter, not religion or philosophy, believes don't have a place here, knowledge has.

We had hacks in the last time against FreeBSD, against the kernel.org site and what not. You simply can't know which site may contain malicious code. regarding the client, nowadays most browsers are either based on Mozilla's engine, on the Webkit engine or are named Opera. What make you think that your browser is not attackable on that base?

A browser that can not be breached must by definition be a browser without any flaw in design and implementation. Such a browser does not exist.

Again, don't be vague, if you have something to say come out with it. I am open to anything that makes sense and it is possible to convince me.

But you still did not come up with any good reason to use a GUI as root, besides laziness and a possibly slightly larger footprint of applications that are running as a different user in the GUI. Both reasons are not important enough to trade security in for them.

There is no such thing as granting or being granted responsibility: you either are or you are not. Everyone is responsible for their own systems but once a system shares a network it becomes responsible for its interaction with other systems. When an owner does not act responsibly that system becomes a potential risk. So advertise corruption, misconceptions, hell, even offer arguments of questionable relevance all you want.
In turn I'll just point out completely avoidable risks.
Cause and effect.

Just on the user's own system no there's no difference. What I had been trying to explain was how one malware could rapidly expand from client to client. It's only possible if it knows how to exploit many versions of client softwares varying from one Linux system to another. At least it would be not always as easy as compared to XP in which its own services itself are the ones which are vulnerable and that packages always have single source of builds. We haven't even considered how it would affect Linux systems that implement other security measures which are not based on the user.
It's not if you include the factor called smart probability.
Yes considered that but I don't think it could create a parasite that would infect my client - after all I run a natively compiled browser with not too common compile flags. Not to mention if I add more security implementations which are not user-based. I also doubt that malwares on servers stay long - at least not significantly often.
If we measure as far as its plugins and flaws in script handling then browsers are vulnerable alright but those things rarely happen now. Most common effective methods for creating successful attacks against browsers are by buffer overlow exploits and the likes, but even them are no longer easy since software versions and builds vary from time to time. For someone like me who compiles my packages natively by default it's just unlikely. And how about other security measures like grsecurity, NX/PAX, hardened compiler, other kernel patches, etc. Thing is I've been running browsers as root for a long time already and I never had a problem. And I do from time to time give minimal assessment if my system is breached. I do consider the possible sneaky attempts if a malware would hide itself just in case you doubt that.

Alright I'll give an example. If your documents are as good as or is more important than your easy-to-restore system would it even matter being root or not when they're breached? Let's assume that you're not on any network that there's a possibility that you would affect other users. Would you even say that users has to learn how to hide their often-accessed files somewhere in a filesystem with disarray and obscurification.
Well that's up to you. I've said enough.Laziness is only laziness if the task in question is significant and/or necessary. And security is only significant if something is needed to be secured and is vulnerable. Those are my opinion for this context. And saying "You'll never know what's coming to you.", well that's already a choice as how you observed things.

You have valid points when you compile your software yourself with an eye to security checks and hardening the system. This will in fact to some extent minimize the risks of possible attacks for your system. It is harder to break into your system, but not impossible, so you could get even better security with building another wall with running your system as user with the least necessary privileges.
As I see it we both have a different approach to security (although I still would not call insisting on the principles I pointed to earlier conservative) and we both have valid points in our approach. So discussing this endlessly will not bring any of us any further.

Let me go back to my sentence that initially started the discussion between us:I will rephrase that to This is unarguably the case most of the time when this question is asked on a forum and to those asking that question it should be made clear that it is a bad idea to run their specific systems as root, with an explanation why that is the case and a pointer to information about basic security principles.

run vlc player as root
 

Thanks its work for me.

Great POST

Run VLC as root
 

Hope this could help you out.

The first half of the opening sentence in that link: I cannot help wondering how many idiots there are out there who think running their systems as root make them hackers. It reminds me of the fools who believe painting pin stripes on their cars make them race care drivers.

That helps no-one.

Kind of like...

If you want to think of yourself as a hacker, you must first learn the most simple and basic of principles of how things work, and why!

I agree with Randicus - this is idiotic advice and the reason given in the article for running something as root is simply wrong, incorrect, stupid, moronic even... might even be considered a malicious posting!

Please do not post wrong, incorrect and harmful information as "helpful", it helps no one and only poisons the knowledge pool.

so you use a hex editor to edit the binary

not good

then you play a vid ( as root ) not that good

then THAT VIDEO ( being a nicly hacked one calls curl to grab a file AS ROOT!!!!
now THAT IS VERY VERY BAD!!!!!

you just instilled a Trojan by playing a video AS ROOT

that is very BAD and you are a "Bleeped bleep" for doing it
Having your credit card stolen from the keyloger YOU LET BE INSTALLED is the least of your problems

That is funny. The guy probably's a wannabe hexer from windows.

If you are going to install a VLC build that allows running on root anyway, just
compile it with --enable-run-as-root.

You have such a good imagination.

And the guy probably thought of donwloading the file to be viewed locally and played it with VLC as root.
He also happens to be too unfortunate for having a vulnerable VLC version with vulnerable blob-parsing libraries
- with vulnerable builds that the exploit despite being generic was luckily able to compromise his system.
He also happens to have a very outdated system not having any kind of kernel-level protection - even
commonly default ones like PaX/NX and ASLR.

resolve root run vlc
 

This is what worked for me. No compilation required.



VLC is not supposed to be run as root. Sorry. – Solution

Anyways, i installed vlc using following command ;

# aptitude install vlc

And tried to run vlc as root i got error on my terminal ;

# vlc

VLC is not supposed to be run as root. Sorry.

If you need to use real-time priorities and/or privileged TCP ports

you can use vlc-wrapper (make sure it is Set-UID root and

cannot be run by non-trusted users first).

This error says straight forward vlc can not be run as root privileged user. What to do now? Don’t be panic. Here is the hacked solution ��

# vi /usr/bin/vlc

search for geteuid and replace it with getppid

Save file & Exit.

Now it should work, try to run it again ��

or

sed -i 's/geteuid/getppid/' /usr/bin/vlc