I am trying to configure Skype on Arch Linux to use a sand boxed user no matter which user calls skype, but I don't particularly like the use of a BASH alias to launch Skype as suggested by the wiki since as far as I can tell if a user is not using BASH or invokes Skype from skype.desktop, the sand boxed user will not be used. I thought it might be better to divert /usr/bin/skype to call

sudo -u skype /usr/bin/skype.real

where skype.real is the actual Skype binary. I am pretty sure in Debian I could do this with

dpkg-divert --package skype --add --rename --divert /usr/sbin/skype.real /usr/sbin/skype

and then add my own file to /usr/sbin/skype. How do I do this with Arch?

  • Does skype-restricted not work? aur.archlinux.org/packages/skype-restricted
    – Darkhogg
    May 11, 2014 at 20:52
  • @Darkhogg I haven't tried it, but I am more interest in the general question of how to modify package files.
    – StrongBad
    May 11, 2014 at 21:04
  • I think that using PKGBUILDs is probably the more general you can get on Arch.
    – Darkhogg
    May 11, 2014 at 21:05

1 Answer 1


If as I suggested on the comments, the skype-restricted AUR package is not suitable for you (and note that I don't know the approach they use), I can think of two approaches:

(Read to the end for the correct way of applying them on Arch)

Change skype to a script that runs your real Skype

Create a bash script that will call your real Skype:

sudo -u skype /usr/bin/skype.real

Give it execute permissions and save it as /usr/bin/skype, renaming the old Skype binary to /usr/bin/skype.real.

This approach leads a few things that needs consideration though:

  • If you really want noone calling Skype (the real one) other than the skype user, you need to give the file the appropriate permissions:

    chown skype /usr/bin/skype.real
    chmod 0100 /usr/bin/skype.real

    This will avoid anyone but its owner to run it

  • In order to let anyone run skype (the new, scripted one), you need to edit the sudoers file (using visudo) so anyone (preferrably in a group, possibly group skype) can call it as user skype. I don't know the details, I just know it can be done.

Change skype owner and set the setuid bit

Note: This is not the recommended way, as setuid executables should be set to a minimum

This migh be cleaner possibility can be setting the setuid bit so anyone calling skype calls it as the user skype.

chown skype /usr/bin/skype
chmod u+s /usr/bin/skype

This will make the skype command available as always, but it will always be run as the skype user.

In any of the above cases, any time you update Skype to a newer version you will need to repeat the process, as pacman will replace the binary.

The solution is to create a PKGBUILD that downloads the official package, extracts it and performs the desired changes. Then you install it manually (as you would install any AUR package). You will need to re-build it manually any time you need to update. Skype doesn't update that often though.

For this las one task, the official wiki on PKGBUILDs are a great resource.

  • Downvote for suggesting an additional setuid binary/script (these should be kept to a minimum). sudo with /etc/sudoers is perfectly capable providing the ability to execute the given /usr/bin/skype.real without password and always as user skype with the script method. May 11, 2014 at 23:43
  • You have the right idea, but recommending users manually move files around is a bad idea. Creating a custom PKGBUILD is absolutely the correct way to handle this.
    – HalosGhost
    May 11, 2014 at 23:45
  • @HalosGhost I edited my answer to highligh the use of a PKGBUILD.
    – Darkhogg
    May 11, 2014 at 23:54
  • @0xC0000022L I added a warning about it not being recommended. I will not remove it, though: It is another method, and is not incorrect, even if its not the best way.
    – Darkhogg
    May 11, 2014 at 23:56
  • 1
    I feel like you should rewrite your answer so that the only thing you recommend is creating a PKGBUILD. Then, the rest of what you offer in your answer, you should frame as being a part of a PKGBUILD. At the moment, you still offer using a PKGBUILD as an after-thought and solution to a separate issue.
    – HalosGhost
    May 11, 2014 at 23:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.