After update, root works but not regular user

English Install/Boot/Login
21

On 2014-02-08 01:46, wolfi323 wrote:

> Although I have to say that I don’t completely understand that comment
> anyway.

Me neither. Probably the person that wrote it (decades ago) was thinking
on another language :wink:

> Ah well, the next paragraph states it’s just a starting point for your
> own system permission configuration in /etc/permissions.local…

Right. I have never known anybody using that mode for real, I mean, non
accidentally. But then, those people might be too paranoid to talk about
it on mail lists and forums! :slight_smile:

>
> @rentpayer:
> Your fstab looks ok, although it’s a bit confusing that you mount cr_tmp
> to /sdb7, and cr_var to /tmp… :wink:

Just my thoughts! :slight_smile:

> Hm.
> Something must change the permissions of /tmp/ at boot then I guess.
> (chkstat is not run automatically on boot, so I would rule out
> /etc/permissions.*)

I guess.

> Maybe something in /etc/tmpdirs.d/ or /etc/tmpfiles.d/ ?
> Could you post /usr/lib/tmpfiles.d/tmp.conf, please?

Concur.

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

22

Please show /etc/crypttab. Wonna bet you have “tmp” option there for cr_var :slight_smile:

23

Here it is:

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

# See tmpfiles.d(5) for details

# Clear tmp directories separately, to make them easier to override
# SUSE policy: we don't clean those directories
d /tmp 1777 root root -
d /var/tmp 1777 root root -

# Exclude namespace mountpoints created with PrivateTmp=yes
x /tmp/systemd-private-*
x /var/tmp/systemd-private-*
X /tmp/systemd-private-*/tmp
X /var/tmp/systemd-private-*/tmp

Also, Arvidjaar requested /etc/crypttab


cr_var_2        /dev/disk/by-id/ata-ST3500413AS_5VMPV5Y6-part5 none       none
cr_swap         /dev/disk/by-id/ata-MAXTOR_STM3320620AS_6QF1BMRR-part8 /dev/urandom swap
cr_ata-ST3500413AS_5VMPV5Y6-part6 /dev/disk/by-id/ata-ST3500413AS_5VMPV5Y6-part6 none       none
cr_tmp          /dev/disk/by-id/ata-MAXTOR_STM3320620AS_6QF1BMRR-part7 none       none
cr_var          /dev/disk/by-id/ata-MAXTOR_STM3320620AS_6QF1BMRR-part1 /dev/urandom tmp

Evidently my various pre-existing partitions, interacting with the installer, got me in a strange naming situation, which caused some update to result in this problem. (Somewhere I got the idea that having smaller partitions was better because they would be easier to back up, but maybe that is no longer true.)
robin-listas observed that

Ah! Your “/” is not encrypted, you are not using LVM. I understand now.
I cannot recall now why I did not think LVM was appropriate here. And the installer would not allow me to encrypt “/”

24

On 2014-02-08 07:16, rentpayer wrote:

> On 2014-02-08 05:46, arvidjaar wrote:

>> Please show /etc/crypttab. Wonna bet you have “tmp” option there for
>> cr_var :slight_smile:

> Code:
> --------------------
>
> cr_var_2 /dev/disk/by-id/ata-ST3500413AS_5VMPV5Y6-part5 none none
> cr_swap /dev/disk/by-id/ata-MAXTOR_STM3320620AS_6QF1BMRR-part8 /dev/urandom swap
> cr_ata-ST3500413AS_5VMPV5Y6-part6 /dev/disk/by-id/ata-ST3500413AS_5VMPV5Y6-part6 none none
> cr_tmp /dev/disk/by-id/ata-MAXTOR_STM3320620AS_6QF1BMRR-part7 none none
> cr_var /dev/disk/by-id/ata-MAXTOR_STM3320620AS_6QF1BMRR-part1 /dev/urandom tmp
>
> --------------------

And arvidjaar is right, you have!

The man page says:


tmp
The encrypted block device will be prepared for using it as /tmp;
it will be formatted using mke2fs(8). This option implies plain.

As it is a totally new filesystem on every boot, it gets defaults
permissions; thus you have to set them yourself on every boot, too. Or
so I would understand, because you’d get those permissions wrong since
day one.

I would not use the tmp option, but perhaps neither the urandom one.
Very secure aka paranoid, but also slower boot and side effects, IMO.

> Evidently my various pre-existing partitions, interacting with the
> installer, got me in a strange naming situation, which caused some
> update to result in this problem.

Something triggered.

> (Somewhere I got the idea that having
> smaller partitions was better because they would be easier to back up,
> but maybe that is no longer true.)

No, it is true, but it depends on what you use as backup media. Someone
I read often used partition of about 4 GiB so that they would fit on a
DVD each. Too small nowdays.

> robin-listas observed that

> Ah! Your “/” is not encrypted, you are not using LVM. I understand now.

I cannot recall now why I did not think LVM was appropriate here. And
the installer would not allow me to encrypt “/”

No, you can’t encrypt “/” with the YaST installer. To do that you need
manual action, and not simple as that (I don’t have it clear what those
actions are and the implications for upgrades).

The YaST way for full system encryption is to create a single encrypted
space, which is given to an LVM container. Inside you have root, home,
and swap.

As it is a single space, you get only one password prompt. It requires a
separate /boot partition, unencrypted.

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

25

Of course crypttab was created by the installer. I may not even have looked at it. I probably do not have a backup of the prior version of crypttab (that is, as of a few weeks ago when I booted OK) and in any case it is difficult to look at backups right now.

I would prefer to keep /tmp encrypted, if proper permissions could be set. If that cannot be done, I will operate with unencrypted /tmp for now. I am not confident that I can figure out how to modify crypttab and fstab (and anything else?) to accomplish either of these objectives without reinstalling.

26

When you are running everything is unencrypted. Encryption only protects you when the machine is turned off. And in that case /tmp no longer exists

27

I thought /tmp is cleared at boot, so if I boot from, say, a DVD, I would be able to see what is on the /tmp partition on the hard drive left over from the last time that drive was used to boot. Never tried it, tho. I don’t remember what is in /tmp. Looking right now on a recently-rebooted system that only uses root I don’t see much.

Anyhow, I don’t think it’s a major loss for me to run with unencrypted /tmp. My question is how exactly to make that change without re-installing OpenSUSE. Or to know that it is not practical to do so, in which case I’ll proceed to reinstall.

28

On 2014-02-08 16:46, rentpayer wrote:

> I would prefer to keep /tmp encrypted, if proper permissions could be
> set. If that cannot be done, I will operate with unencrypted /tmp for
> now. I am not confident that I can figure out how to modify crypttab
> and fstab (and anything else?) to accomplish either of these objectives
> without reinstalling.

With any plain text editor.

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

29

OK, I need to rephrase my description of the problem:
I would prefer to keep /tmp encrypted, if proper permissions could be
> set. If that cannot be done, I will operate with unencrypted /tmp for
> now. I need to know what modifications to make in crypttab
> and fstab (and anything else?) to accomplish either of these objectives
> without reinstalling.

30

On 2014-02-09 01:06, rentpayer wrote:
>
> gogalthorp;2623232 Wrote:
>> When you are running everything is unencrypted. Encryption only protects
>> you when the machine is turned off. And in that case /tmp no longer
>> exists
> I thought /tmp is cleared at boot,

Not by default.

> so if I boot from, say, a DVD, I
> would be able to see what is on the /tmp partition on the hard drive
> left over from the last time that drive was used to boot.

Yes, absolutely correct.

> Anyhow, I don’t think it’s a major loss for me to run with unencrypted
> /tmp. My question is how exactly to make that change without
> re-installing OpenSUSE. Or to know that it is not practical to do so, in
> which case I’ll proceed to reinstall.

I’m not familiar with the “tmp” option you are using. All my encrypted
partitions use “none none” or “none noauto”.

You are also using “/dev/urandom”, which means that the encrypted space
is created on every boot with a random password.

Using “none” you get prompted for the password on every boot (perhaps
one prompt for each partition), and the space is persistent, not erased.
It has to be created once, manually. This would have to be done using a
live system.

I would wait to see if arvidjaar has some other suggestion before doing
anything else. I have some ideas, but this situation is unfamiliar to me.

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

31

On 2014-02-09 01:36, rentpayer wrote:

> OK, I need to rephrase my description of the problem:
> I would prefer to keep /tmp encrypted, if proper permissions could be
> set. If that cannot be done, I will operate with unencrypted /tmp for
> now. I need to know what modifications to make in crypttab
> and fstab (and anything else?) to accomplish either of these
> objectives without reinstalling.

You can jsut reset those permissions on every boot, automatically.

For example, with a cron job, using the “@reboot” field (see man 5
crontab). Or perhaps do it in “/etc/init.d/before.local” or
“/etc/init.d/after.local”

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

32

I added a line

@reboot chmod a+w,o+t /tmp    >dev/null 2>&1

at the end of /etc/crontab and rebooted. Got the same command line prompt that I had been getting. The difference was that this time, the

init 3
init 5

worked properly, giving me the normal screen wherefrom I could get to a normal user’s desktop.

The problem is solved, or at least worked around, and I have made notes as to how this is done as it may be needed in future reboots.

One point of interest, I found that crypttab has not been updated since my original install in December. fstab, however, was edited Jan 30 (by some update, not by me), meaning that it would have first affected the Feb 7 reboot.

I will be watching here, especially in case arvidjaar or someone else gives me some guidance how to clean up cryptab and/or fstab. Comes the next upgrade, I will give attention to getting a simpler, clearer scheme of partitions.

Thanks to all for the support.

33

That’s most likely race condition between cron and xdm on startup. Remove your crontab entry and use tmpfiles instead, they should be running early enough before xdm is ever started:


echo "m /tmp 1777" > /etc/tmpfiles.d/fix_tmp_permissions.conf

File name does not matter but must have “.conf” suffix.

34

BTW in the past permissions were explicitly set by /etc/init.d/boot.crypto. If this configuration was indeed created by installer automatically, bug report is in order, but I cannot reproduce it - if I create encrypted partition for /tmp after installation, it is created as normal with explicit password and no “tmp” option.

That said, it is still regression in systemd integration and bug report is still needed; just that it probably is not high priority unless someone provides evidence that installer does it for encrypted /tmp.

https://bugzilla.novell.com/show_bug.cgi?id=862975

35

On 2014-02-09 06:56, arvidjaar wrote:

> That’s most likely race condition between cron and xdm on startup.
> Remove your crontab entry and use tmpfiles instead, they should be
> running early enough before xdm is ever started:

Ah, I like that method better.

On 2014-02-09 07:46, arvidjaar wrote:

>
> BTW in the past permissions were explicitly set by
> /etc/init.d/boot.crypto.

Ah… I start to understand. Thanks.

> That said, it is still regression in systemd integration and bug report
> is still needed; just that it probably is not high priority unless
> someone provides evidence that installer does it for encrypted /tmp.
>
> https://bugzilla.novell.com/show_bug.cgi?id=862975

AH, you have reported it already. Thanks.

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

36

That didn’t work. It just gave me the command line login as before. So I have gone back to the method described in my previous message.

I am not familiar with the “m” command and found no man page for it.

37

On 2014-02-09 16:56, rentpayer wrote:
>
> arvidjaar;2623334 Wrote:
>> That’s most likely race condition between cron and xdm on startup.
>> Remove your crontab entry and use tmpfiles instead, they should be
>> running early enough before xdm is ever started:>
> Code:
> --------------------
> > >
> > echo “m /tmp 1777” > /etc/tmpfiles.d/fix_tmp_permissions.conf
> --------------------
>>>
>> File name does not matter but must have “.conf” suffix.
>
> That didn’t work. It just gave me the command line login as before. So
> I have gone back to the method described in my previous message.
>
> I am not familiar with the “m” command and found no man page for it.

No, it is a systemd feature for creation and maintenance of temporary
directories. It is a configuration option for such. See “man tmpfiles.d”

You have to create a file in the directory “/etc/tmpfiles.d/” named, for
instance, “fix_tmp_permissions.conf”, containing this line:


m /tmp 1777

and the man page says it does this:


m
If the specified file path exists adjust its access mode,
group and user to the specified values and reset the SELinux
label. If it doesn't exist do nothing.

If that does not work, please scan the /var/log/messages file to see if
it says something, and copy that back here.

As an alternative, I would consider writing a line in the
/etc/init.d/boot.local file:


chmod /tmp ....
/bin/logger -t Mine -p syslog.info "Adjusting /tmp permissions"

Te second line writes an entry in “/var/log/messages” so that, if it
does not work, you can find out if the script did run or not.

I expect this script does run under systemd. On a freshly installed 13.1
system I see these files:


-rwxr--r-- 1 root root 378 Oct 21 23:12 /other/etc/init.d/boot.local
-rwxr--r-- 1 root root 343 Oct 21 23:12 /other/etc/init.d/halt.local
-rwxr--r-- 1 root root 505 Oct 21 23:12 /other/etc/init.d/before.local
-rwxr--r-- 1 root root 520 Oct 21 23:12 /other/etc/init.d/after.local

It is not clear when each runs, though (or even /if/ they do - the
coments are dated decades ago).

If it runs, I expect /etc/init.d/boot.local to run very early.

But it would be much cleaner to make the tmpfile.d entry to work.

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

38

I found why. To cut long story short - you do not need custom tmpfiles.d (one is already shipped with system by default) but it did not work because fstab entry had “nofail”. If you remove it, it works.

39

On 2014-02-10 19:26, arvidjaar wrote:
>
> rentpayer;2623413 Wrote:
>> That didn’t work.
>
> I found why. To cut long story short - you do not need custom tmpfiles.d
> (one is already shipped with system by default) but it did not work
> because fstab entry had “nofail”. If you remove it, it works.

Interesting. I read the bugzilla report. So, neither “nofail” nor
“noauto” should be used.

Well, if YaST does set it up that way, there is a YaST bug instead.

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

40

I think “nofail” was used to mimic previous behavior - so that system would still boot even if container failed to decrypt. For this specific use case it is probably safe to remove it - nobody even tries to decrypt “tmp” containers. But as already mentioned, YaST did not configure it this way when I tried it, at least on 13.1.