Desktop free of pam, consolekit, policykit, *kits

[llemikebyw]

I am seeking to build a Gentoo desktop system that is free of the following:

1) Linux PAM
2) FreeDesktop's PolicyKit/polkit
3) FreeDesktop's ConsoleKit
4) FreeDesktop's systemd
5) FreeDesktop's udev > 171 - I expect to eventually swap the system to eudev when eudev is sufficiently matured
6 I won't want PackageKit either but that's another story...

Each of these Projects are supported/hosted by Fedora/Red Hat and the ultimate direction of the development of these packages is targeted towards GnomeOS.

I have been a long term advocate of KDE but due to their earlier decisions to incorporate PAM and *kits as dependencies I am now considering alternative desktops (Reliance on *kits seems to be becoming unavoidable).

After taking the last couple of days to ensure that PAM had been eradicated from my system (New Installation - Not my first of Gentoo, I would add); I find now that KDE and Xfce are trying to pull in PolicyKit (and ConsoleKit) despite the fact I have the following USE flags set in:

Code: Select all

/etc/make.conf
and
/etc/portage/make.conf

Code: Select all

USE="-gnome -kde -policykit -consolekit -pam..."

Furthermore I have set ">sys-libs/pam-0" in /etc/portage/package.mask

I believe that KDE can be built without PolicyKit and ConsoleKit but at the moment emerge seems to be insisting that I allow polkit and consolekit despite the flags. Obviously not -kde for KDE Build!! .
Unfortunately, Xfce seems to have the same dependencies.

I do have udev enabled in USE.

Is it possible to alter the ebuilds of KDE or Xfce to prevent dependencies on the *kits? Is there an easier way than that?

I'm really after a "Yes - keep searching" or "No - there's now a hard dependency on...." type of answer. But if you've the time to elaborate then I would be very interested.

I'm off now to continue my odyssey with this machine...

Mike

P.S. I can see PAM coming back onto another system later but I needed to know it could be removed... and Success

[The Doctor]

Welcome to the Gentoo forums!

The reason that KDE is pulling consolekit is because upstream will not support a kit-less install. To this end, the gentoo devs don't want you to disable it unless you know what you are doing. You need to switch to a different profile and fake the KDE profile. Use emerge --info before and after the switch to see what you need. Alternatively, you can use a <something>.<something> to remove the block. As you can see, I did not do this and I don't remember the file.

This will get you past this particular point. I don't know about PAM, but *kitless is easily possible with KDE. I would mask it and see who complains. For my purposes, I mask projects I don't want to haunt me. That way, portage warns me about that depends on gnome-base/*, consolekit, upower, etc.

I would also recommend eudev. I am using it (and *kit free KDE) with absolutely no problem here. Good luck.

EDIT: it will be sufficient to simply enter sys-libs/pam in package.mask if you wish to mask pam. You only need versions if you want to stop an upgrade passed your desired target.

EDIT2: I can set -pam and portage will happily remove pam from my system. I do not know what effect this would have on your system, but portage will let you do this with KDE. packagekit also depends on consolekit, so removing it kills 2 birds with one stone, so to speak.

EDIT3: comment out everything in /etc/make.conf. It is an old file and it is being moved to /etc/portage/make.conf. Using both files can cause strange errors.

[PaulBredbury]

I run XFCE without consolekit and policykit/polkit and systemd (but not in Gentoo) - just FYI that it's perfectly possible.

[llemikebyw]

Dear Doctor,
Thank you for all your comments. I perchance hadn't made it clear regarding PAM. It is gone. Off the system. System rebuilt fine. Took me a gcc-config to complete though and a couple of world rebuilds. Your comments on KDE will be fully researched. Thank you for suggesting some directions I might take. I like your idea about moving off the Desktop profile and building KDE under another profile and more masks, eh? Hmm... I'm doing that with my PAM setting in /etc/portage/package.mask and it is working for PAM... hmmm...


Dear Mr. Watchman,
I like your comment: "not in Gentoo"... you wouldn't have built a Xfce port on an UNIX OS, say. Not OpenBSD perchance or FreeBSD? Naughty

I'm in the process on another machine...

Or, can Watchmen also be slackers?

Thanks for all the help.

Mike

[PaulBredbury]

Maybe OpenPAM is a palatable alternative to Fedora's PAM? It's in Gentoo.

[Dominique_71]

You can also take a look at pmount-gui + *kit free system

[steveL]

What Dominique said: you need to add an /etc/portage/profile/use.force file (see ppurka's post for details.) It's handy as you can force off eg -3dnow -3dnowext if you're on an Intel CPU, for example.

I've been following their advice, as you'll see from that thread, and it rocks. It wasn't my goal, but my machine actually started running a bit quicker after I got rid of the nubkit stuff.

What is this about PAM? I've always liked PAM, but if there's some future "strategic direction" bs coming, I'd like to know about it, so I can think about switching as Paul mentioned.

[wcg]

I still have pam installed, but I run a *kit free, no-systemd xfce
for a desktop on Gentoo. This required not installing thunar,
the xfce file manager, and close attention to xfce plugins to
be sure they were not using xfce's gnome support. The only
thing that pulls in any gnome dependencies now is Gnupg, afaik.

I do not have udev in USE= in /etc/portage/make.conf. The
only thing in package.use that has the udev USE flag enabled
is xorg-server. (I am not sure xorg-server needs it, but I got
the impression from some emerge message that it would
simplify things for the xorg-server ebuild, and so far it does
not seem to hurt. udev-171-r9, with >=sys-fs/udev-181
masked off in package.mask.)

I do not have pam in USE= in /etc/portage/make.conf, but
it is in my profile, so I expect that every package that checks
for it sees it. pam predates Gnome, but if their development
is under the same management, I suppose it could become
a source of problems. That could adversely affect a lot of
servers to whom desktop issues are simply irrelevant, though.

Nice to know you can drop-kick pluggable authentication
modules if the need arises, though.

[Dominique_71]

What Dominique said: you need to add an /etc/portage/profile/use.force file (see ppurka's post for details.) It's handy as you can force off eg -3dnow -3dnowext if you're on an Intel CPU, for example.

I don't need it, so I don't used it. In fact I was not aware of it when I done this change. Thanks for the remaining!

I use mostly /etc/make.conf, but after making those 2 profiles, the number of flags in make.conf was divided by 3 at least. And of course /etc/portage/package.use.

[PaulBredbury]

This required not installing thunar

I assume that Gentoo is pulling in more deps than necessary. Thunar doesn't need any *kit, in both XFCE 4.8 and 4.10.

I don't see the problem with udev - we had fork (which works fine), and eudev in future, and also Debian/Ubuntu/Mint will have to decide on something to use.

[soka]

For Thunar to not pull any *kit dependency you have to emerge it without the udev flag.

Code: Select all

echo "xfce-base/thunar -udev" >> /etc/portage/package.use
emerge -va thunar

[Ant P.]

I've been running all my Gentoo systems without PAM for about 7-8 years. udev took a few days of dependency hell to purge (and I've had to manually edit x11-overlay packages because they haven't fixed their dependencies yet). I'm running a KDE desktop with no *kits installed.

[The Doctor]

I don't see the problem with udev - we had fork (which works fine), and eudev in future, and also Debian/Ubuntu/Mint will have to decide on something to use.

The first fork is dead:

I'm sorry to announce this, but both me and consus decided to abandon the development of this fork. Too much of bad [Mod edit for language. — [profile=101148]JRG[/profile]] code and not enough free time. Repo and overlay will still be accessible.

You can either try to use gentoo devs' fork, stick to an older version, or remove udev completely since most of it's functions are moved to the kernel (I chose the later option).

Thanks to everyone who took part in the development. It was cool

I would go with eudev, since this fork has no future. I have been using eudev since this fork died 2 months ago, and so far it is working just fine.

[SamuliSuominen]

- Thunar with USE="udev" enabled will pull in gnome-base/gvfs with USE="udev udisks" (This is UDisks2 and will required new udev) or alternatively USE="udev gdu" enabled (This is UDIsks1 and will be satisfied also by old udev)
But you also have to disable USE="dbus" for Thunar. USE="dbus" in Thunar doesn't really do anything wthout gnome-base/gvfs, it is used for communication with gnome-base/gvfs, therefore it will pull in the required package.

- xfce4-session will pull in *kits if USE="consolekit" or USE="policykit" is enabled. USE="udev" will also pull in upower which pulls in *kits. They are used for rebooting/shutdown/hibernate/suspend. If these all are disabled, it will fallback to using
sudo if it is installed. With sudo you can only reboot/shutdown.

So for old-style Xfce install you have to disable quite a lot of default set USE flags, these are mostly set in the desktop profile. Users of plain 10.0 profile will not have this "problem" as it assumes users know what they are doing and lets them set these USE flags themselfs.

So you don't have to "edit" any of the Xfce ebuilds, the logic is there to get sudo-only desktop. Also the dependencies are very minimal, nothing unnecessary is getting pulled in, seriously, they reflect the configure.{ac,in} as suplied by upstream.

Disabling USE="dbus" for Thunar makes the Trash not work, therefore it's a bit tricky to disable it, there is no point in providing broken file manager by default. When files get deleted without Trash and without hitting shift-delete combination, the files just get moved to Trash directory and user has no options within filemanager to empty it, except switching to the Trash directory and deleting the files "by hand". We don't support this kind of setup really.

Xfce doesn't pull in any "gnome" dependencies, gnome-base/gvfs should be considered as extension to the dev-libs/glib -> GVfs is GIO/GLIB VFS. It is not an gnome-only package.

Futhermore udev-171 is completely dead package and does NOT work with kernels higher than 3.2 without issues. Have fun using vulnerable kernels I guess, or use eudev.

[Fran]

I run a system without udisks, upower, *kit, etc. Just eudev. Quite easy (just remove the USE flags and reinstall) and everything works (udevil to replace udisks and sudo poweroff/reboot to replace upower ).

But why would you want to remove pam? pam rocks. I use pam_ssh to start ssh-agent and pam_encfs (not in portage) to mount my encrypted safe directory at boot with just the login password. And the directory is dismounted automagically when I log out

[DaggyStyle]

Futhermore udev-171 is completely dead package and does NOT work with kernels higher than 3.2 without issues. Have fun using vulnerable kernels I guess, or use eudev.

I'm using kernel 3.7.1 with latest stable udev-171-r* without any problems.

[SamuliSuominen]

Futhermore udev-171 is completely dead package and does NOT work with kernels higher than 3.2 without issues. Have fun using vulnerable kernels I guess, or use eudev.

I'm using kernel 3.7.1 with latest stable udev-171-r* without any problems.

And you have to select between non-working /dev/cdrom symlink vs. non-working path-by-id symlinks for disks... along other problems. Sure it will work for some systems which don't use these features.

[Anon-E-moose]

Futhermore udev-171 is completely dead package and does NOT work with kernels higher than 3.2 without issues. Have fun using vulnerable kernels I guess, or use eudev.

I'm using kernel 3.7.1 with latest stable udev-171-r* without any problems.

And you have to select between non-working /dev/cdrom symlink vs. non-working path-by-id symlinks for disks... along other problems. Sure it will work for some systems which don't use these features.

Udev 171-r6 seems to be working on 3.4.10 without any problems and a working cdrom.
But what do I know, I'm just running a vulnerable kernel.

I am seeking to build a Gentoo desktop system that is free of the following:

1) Linux PAM
2) FreeDesktop's PolicyKit/polkit
3) FreeDesktop's ConsoleKit
4) FreeDesktop's systemd
5) FreeDesktop's udev > 171 - I expect to eventually swap the system to eudev when eudev is sufficiently matured
6 I won't want PackageKit either but that's another story...

It is possible to run a system this way, if you are aware of the few drawbacks.
File managers lose easy auto-mounting of filesystems, etc.

I personally run a single user system, and don't need all that fluff.
I don't use PAM, *kit, systemd, udisks/upower/u-whatever except udev and it's 171-r*.

I also swapped out xfce (long ago) for lxde because I got tired of xfce trying to be gnome-light.
Even with that, I do have to disable the udev stuff inside pcmanfm (yes I lose auto-mounting) but
I've been using unix systems since before linux was even thought about being started
and have no problem with using command line to mount/umount filesystems, cdroms, etc.

So despite some of the things said earlier, you can run systems without all the things mentioned in your
quote and have a functional and safe system. Just choose to know what you are doing.

Good luck

RANT
I'm not sure what is with this big business type philosophy of one size fits all,
the developer know best attitude that has been creeping into the linux world
for a while. But this is linux, choice should be honored without ridicule
simply because others don't want or need such things as systemd, u*, *kit, etc.
And no this is not pointed at anyone in this thread, just something I've noticed across various threads.
/RANT

Edit to add: color red is edit

[DaggyStyle]

Futhermore udev-171 is completely dead package and does NOT work with kernels higher than 3.2 without issues. Have fun using vulnerable kernels I guess, or use eudev.

I'm using kernel 3.7.1 with latest stable udev-171-r* without any problems.

And you have to select between non-working /dev/cdrom symlink vs. non-working path-by-id symlinks for disks... along other problems. Sure it will work for some systems which don't use these features.

I think my cdrom works ok as far as I can remember. moreover I run hotplug multiseat setup and didn't encountered any issues.
if it doesn't work, why is it possible? mask that combination. what you currently say is that gentoo supports a broken setup.

[mv]

But why would you want to remove pam?

It is an additional layer. For security-relevant things you should have only the absolutely necessary complexity. If you really need the features of pam, you have no choice, but if you don't (which is the case for most desktops), installing it is an unnecessary security risk.

[sitquietly]

.....
Futhermore udev-171 is completely dead package and does NOT work with kernels higher than 3.2 without issues. Have fun using vulnerable kernels I guess, or use eudev.

udev-171 is completely dead?!

Funtoo "current" uses udev-171. On my funtoo install I have udev-171 with gentoo kernel 3.7.2. Everything is working properly under kde 4.9.5 (usb automounting, device handling, power management, ..., it's all good).

On my gentoo ~amd64 install I have udev-197 with the same kernel. kde works identically on both systems, with udev-171 or udev-197. I can see no differences.

[wcg]

Here is thunar's "emerge -Dp thunar" list, without udev in USE flags
on one system:

Code: Select all

These are the packages that would be merged, in order:

Calculating dependencies  .... done!
[ebuild  N     ] dev-util/desktop-file-utils-0.21  USE="-emacs" 
[ebuild   R    ] sys-fs/udev-171-r9  USE="gudev*" 
[ebuild   R    ] virtual/udev-171  USE="gudev*" 
[ebuild  N     ] dev-libs/libtasn1-2.13  USE="-doc -static-libs" 
[ebuild  N     ] dev-libs/nettle-2.5  USE="gmp" 
[ebuild  N     ] gnome-base/orbit-2.14.19-r1  USE="-debug -doc {-test}" 
[ebuild  N     ] net-libs/gnutls-2.12.20  USE="cxx nettle nls zlib -bindist -doc -examples -guile -lzo -pkcs11 -static-libs {-test}" 
[ebuild  N     ] net-libs/libproxy-0.4.10-r1  USE="-gnome -kde -mono -networkmanager -perl -python -spidermonkey {-test} -webkit" 
[ebuild  N     ] net-libs/glib-networking-2.32.3  USE="libproxy ssl -gnome -smartcard {-test}" 
[ebuild  N     ] gnome-base/gconf-2.32.4  USE="gtk introspection -debug -ldap -policykit" 
[ebuild  N     ] net-libs/libsoup-2.38.1  USE="introspection samba ssl -debug {-test}" 
[ebuild  N     ] gnome-base/gnome-keyring-2.32.1-r1  USE="pam -debug {-test}" 
[ebuild  N     ] gnome-base/libgnome-keyring-2.32.0  USE="-debug {-test}" 
[ebuild  N     ] net-libs/libsoup-gnome-2.38.1  USE="introspection -debug" 
[ebuild  N     ] gnome-base/gvfs-1.12.3  USE="http samba udev -afp -archive -avahi -bluetooth -bluray -cdda -doc -fuse -gdu -gnome-keyring -gphoto2 -ios (-udisks)" 
[ebuild  N     ] xfce-base/thunar-1.4.0  USE="dbus pcre startup-notification -debug -exif -libnotify {-test} -udev" XFCE_PLUGINS="-trash" 

The following USE changes are necessary to proceed:
#required by gnome-base/gvfs-1.12.3[udev], required by xfce-base/thunar-1.4.0[dbus,-xfce_plugins_trash], required by thunar (argument)
=virtual/udev-171 gudev
#required by virtual/udev-171, required by gnome-base/gvfs-1.12.3[udev], required by xfce-base/thunar-1.4.0[dbus,-xfce_plugins_trash], required by thunar (argument)
=sys-fs/udev-171-r9 gudev

Even without the *kits, there is still a lot of "gnome chrome" there that I don't want
to see showing up in "emerge -DuNp world" output whenever it is updated.

Incidentally, what exactly does the gudev USE flag do?

[DaggyStyle]

Here is thunar's "emerge -Dp thunar" list, without udev in USE flags
on one system:

Code: Select all

These are the packages that would be merged, in order:

Calculating dependencies  .... done!
[ebuild  N     ] dev-util/desktop-file-utils-0.21  USE="-emacs" 
[ebuild   R    ] sys-fs/udev-171-r9  USE="gudev*" 
[ebuild   R    ] virtual/udev-171  USE="gudev*" 
[ebuild  N     ] dev-libs/libtasn1-2.13  USE="-doc -static-libs" 
[ebuild  N     ] dev-libs/nettle-2.5  USE="gmp" 
[ebuild  N     ] gnome-base/orbit-2.14.19-r1  USE="-debug -doc {-test}" 
[ebuild  N     ] net-libs/gnutls-2.12.20  USE="cxx nettle nls zlib -bindist -doc -examples -guile -lzo -pkcs11 -static-libs {-test}" 
[ebuild  N     ] net-libs/libproxy-0.4.10-r1  USE="-gnome -kde -mono -networkmanager -perl -python -spidermonkey {-test} -webkit" 
[ebuild  N     ] net-libs/glib-networking-2.32.3  USE="libproxy ssl -gnome -smartcard {-test}" 
[ebuild  N     ] gnome-base/gconf-2.32.4  USE="gtk introspection -debug -ldap -policykit" 
[ebuild  N     ] net-libs/libsoup-2.38.1  USE="introspection samba ssl -debug {-test}" 
[ebuild  N     ] gnome-base/gnome-keyring-2.32.1-r1  USE="pam -debug {-test}" 
[ebuild  N     ] gnome-base/libgnome-keyring-2.32.0  USE="-debug {-test}" 
[ebuild  N     ] net-libs/libsoup-gnome-2.38.1  USE="introspection -debug" 
[ebuild  N     ] gnome-base/gvfs-1.12.3  USE="http samba udev -afp -archive -avahi -bluetooth -bluray -cdda -doc -fuse -gdu -gnome-keyring -gphoto2 -ios (-udisks)" 
[ebuild  N     ] xfce-base/thunar-1.4.0  USE="dbus pcre startup-notification -debug -exif -libnotify {-test} -udev" XFCE_PLUGINS="-trash" 

The following USE changes are necessary to proceed:
#required by gnome-base/gvfs-1.12.3[udev], required by xfce-base/thunar-1.4.0[dbus,-xfce_plugins_trash], required by thunar (argument)
=virtual/udev-171 gudev
#required by virtual/udev-171, required by gnome-base/gvfs-1.12.3[udev], required by xfce-base/thunar-1.4.0[dbus,-xfce_plugins_trash], required by thunar (argument)
=sys-fs/udev-171-r9 gudev

Even without the *kits, there is still a lot of "gnome chrome" there that I don't want
to see showing up in "emerge -DuNp world" output whenever it is updated.

Incidentally, what exactly does the gudev USE flag do?

I really don't understand why people don't use the -t switch when posting such outputs, can you please add the -t switch and post the output?

[wcg]

I will consider adding the "-t" option to "emerge -DuNp" output
in future, but I do not think it is relevant here. This is not
a question of "what depends on what" within the thunar
dependencies. It is simply the aggregate of updates to
gnome stuff that becomes annoying (on a system not using
gnome desktop).

[DaggyStyle]

I will consider adding the "-t" option to "emerge -DuNp" output
in future, but I do not think it is relevant here. This is not
a question of "what depends on what" within the thunar
dependencies. It is simply the aggregate of updates to
gnome stuff that becomes annoying (on a system not using
gnome desktop).

you might be amazed how much it helps to understand what the hell is going on.