3

Is it possible to change the location for .Xauthority, to something other than $HOME/.Xauthority ? AFAIU, this file is being created every time I log into LXDE, by my login manager slim.

The problem I am having is following:

I want to set my home to "immutable" using extended attributes:

chattr +i /home/martin/

This way, no applications can save their files directly in /home/martin/, but they can still save files in directories located lower levels of my home, i.e. /home/martin/.config/.

At the moment, when I set my home to immutable, I cannot login to LXDE because the login manager (slim) cannot create /home/martin/.Xauthority. This happens even if the old .Xauthority exists. The login manager could just overwrite the old file with new data, but apparently this is not what it does. It creates a new file and deletes the old one. This is not allowed when /home/martin is immutable (overwriting existing file would be allowed).

Therefore, I would like to store .Xauthority somewhere else, such as .config/.Xauthority. Is this possible?

I know that xauth takes the parameter -f where file path can be specified.

UPDATE:

looking at the source code of slim, I think I might have found the place where .Xauthority is being deleted and created again:

string xauthority = pw->pw_dir;
xauthority.append("/.Xauthority");

...

/* reinitialize auth file */
authfile = cfg->getOption("authfile");
remove(authfile.c_str());
putenv(StrConcat("XAUTHORITY=", authfile.c_str()));
Util::add_mcookie(mcookie, ":0", cfg->getOption("xauth_path"),
  authfile);

How could I change the source code, so that file gets overwritten, rather than deleted/created ?

  • Have you looked into exporting a modified XAUTHORITY environment variable before the X session is started? it's probably simpler and more maintainable than rolling a custom version of your display manager. – steeldriver Dec 21 '14 at 13:14
  • @steeldriver - but how can I export XAUTHORITY variable for a user BEFORE the user can log in ? – Martin Vegter Dec 21 '14 at 13:15
  • AFAIK it doesn't need to be done before the user logs in, just before the user's X session is started - I don't know the startup sequence for SLiM, but perhaps it's possible via an ~/.xinitrc file? – steeldriver Dec 21 '14 at 13:25
  • 1
    Could you explain why in the world you would want to set $HOME to immutable? There are many, many files that are automatically created there (I have 109 dotfiles in my ~/ for example). Not all programs use the ~/.config directory and you will face all sorts of issues. This is really not a very good idea. – terdon Dec 21 '14 at 13:43
  • @terdon - I don't know why you have 109 dotfiles in your home. I have only 6: .Xauthority .bashrc .gitconfig .netrc .profile .xscreensaver, plus dot-directories such as .config. The reason why i want home immutable is, I dont want applications to create files in my home, either by mistake or intent. Also, I want to prevent mistakes by myself. It is easy to mistype and accidentally copy files to $HOME (it happened to me with scp several times alredy), and thereby overwrite existing files. – Martin Vegter Dec 21 '14 at 14:07
1

The location of the X cookie file can be configured with the XAUTHORITY environment variable. The default is ~/.Xauthority.

Of course, the location that you pass to applications has to match the location where the cookie is stored. SLiM doesn't offer a way to add the cookie to a different file: it has ~/.Xauthority hard-coded. If you want to use a different file, patch SLiM or use a display manager that happens to have this configuration option. For example, Gdm stores X cookies under /var/run/gdm.

I think you can make .Xauthority a symbolic link, if you don't want the modifiable file to be in your home directory.

Making your home directory immutable is an exercise in futility. You're likely to encounter many other similar issues. The standard place for configuration files and state files is your home directory — that's where dot files get their name, because they start with a . so that ls won't list them by default.

  • 1
    I don't see it as futile at all. When I use different login manager (wdm) immutable home works great (.Xauthority will be created in /tmp, if home is not writable). I am surprised that gdm stores it in /var/run/gdm. The file is being created with the user privileges, not root. How can user write to /var/run/gdm ? – Martin Vegter Dec 22 '14 at 10:38
  • 1
    also, don't forget that once an application has created a dotfile, you can change home to immutable. The application should not need to create more files, and can modify the existing file. You only need to make home mutable once, when new application needs to create a file for the first time. The benefit of immutable home is, it protects me from accidentally overwriting files in my home. As a side note: I consider it a very bad idea to store important configuration files in home directly, It reminds me of the bad practice of Windows, where config files and user data are mixed together. – Martin Vegter Dec 22 '14 at 10:44
  • Martin Vegter.... It is a little more than that... .Xauthority needs to be writable true, BUT it also needs to create lock files like .Xauthority-c at least temporarily. – anthony Feb 27 at 0:37

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.