Please share examples of login.conf.d

uxer

OpenBSD 7.1

Introduced support for storing capability databases in /etc/login.conf.d, allowing easy addition of custom login classes from packages and made rcctl(8) look for the login class in both login.conf and login.conf.d/${class}.

What exactly is the syntax of login.conf.d/${class}? Say, /etc/login.conf.d/staff?
This like:

:datasize-cur=1536M:\
:datasize-max=infinity:\
:maxproc-max=1024:\
:maxproc-cur=512:\
:openfiles-max=8192:\
:openfiles-cur=4096:\
:stacksize-cur=32M:\
:ignorenologin:\
:requirehome@:\
:tc=default:

Or this like

staff:\
        :datasize-cur=1536M:\
        :datasize-max=infinity:\
        :maxproc-max=1024:\
        :maxproc-cur=512:\
        :openfiles-max=8192:\
        :openfiles-cur=4096:\
        :stacksize-cur=32M:\
        :ignorenologin:\
        :requirehome@:\
        :tc=default:

Or how?

Values partially from https://www.c0ffee.net/blog/openbsd-on-a-laptop/
Are these sane?

https://man.openbsd.org/login.conf

A special record, “default”, in /etc/login.conf is used for any user without a valid login class in /etc/master.passwd.

default being a "special record", is it eligible for /etc/login.conf.d/default as any other?

rvp

uxer It's a capability record so it has to start with a name. See cgetent(3), section Capability database syntax

uxer

rvp

https://man.openbsd.org/OpenBSD-7.1/cgetent.3#Capability_database_syntax

Capability databases consist of a series of records, one per logical line.

Do I understand it correctly: in login.conf:
auth-defaults, auth-ftp-defaults, default, daemon, staff, authpf, pbuild, bgpd, unbound and xenodm are names of the records.
Of which default, daemon, staff, authpf, pbuild, bgpd, unbound and xenodm are login classes.
The login.conf database itself has no means of distinguishing which records are classes and which are not, this work is done externally.

If my understanding is correct, then you have to specify a class twice: in filename login.conf.d/${class} and in record name, right?
What if you put, e.g. my_class_1 record name into login.conf.d/my_class_2 or several classes into a single login.conf.d/${class}?

/etc/rc.d/rc.subr will just not find rogues:

...
getcap -f /etc/login.conf.d/${_name}:/etc/login.conf ${_name} 1>/dev/null 2>&1 && \
...

but would another logic be employed, then login.conf.d/${class} is not actually as strict as containing a single class?
Or should it be understood as login.conf.d/${class} is meant to consist of a single class record (and maybe additional non-class records for tc= interpolation/expansion), and the fact that you can put there other records with other classes names is an implementational loose end?

rvp

uxer auth-defaults, auth-ftp-defaults, default, daemon, staff, authpf, pbuild, bgpd, unbound and xenodm are names of the records.

Yes.

uxer Of which default, daemon, staff, authpf, pbuild, bgpd, unbound and xenodm are login classes.

They're records treated as login classes by certain programs.

uxer The login.conf database itself has no means of distinguishing which records are classes and which are not, this work is done externally.

In a way. From the point of view of the capability access functions (cgetent and friends) they're just records in a database called login.conf. Programs which use that database impose meanings on certain record-names

uxer If my understanding is correct, then you have to specify a class twice: in filename login.conf.d/${class} and in record name, right?

Correct.

uxer What if you put, e.g. my_class_1 record name into login.conf.d/my_class_2 or several classes into a single login.conf.d/${class}?

You would get duplicates. And, cap_mkdb ignores these:

$ cap_mkdb login.conf 
cap_mkdb: ignored duplicate: default
cap_mkdb: ignored duplicate: standard
cap_mkdb: ignored duplicate: xuser
cap_mkdb: ignored duplicate: staff
cap_mkdb: ignored duplicate: root
cap_mkdb: ignored duplicate: daemon
cap_mkdb: ignored duplicate: news
cap_mkdb: ignored duplicate: dialer
$

Other programs which read the text file instead of the db might well merge them--don't know.

uxer Or should it be understood as login.conf.d/${class} is meant to consist of a single class record

That's a convenience provided by OpenBSD 7.1 for 3rd-party programs--as the release notes explains. Lumping all records into a single /etc/login.conf makes record updation and removal a pain: All programs have to read the entire DB, remove/add/modify only their record, then write the whole thing back; and you'll have to use a lock to prevent other programs from stomping all over your changes.

uxer Will capabilities of a record be merged, duplicates preferred [...]

This one you should be able to figure out on your own. Make duplicate capabilities (and records) and see what's merged and what's updated.

Your post #4 and #6 I'll look into when I get the time, though surely you can do #4 on your own.
#6 seems to be a case of:

loop, recursive:
    See: recursive loop
...
recursive loop:
    See: loop, recursive
...

Somebody's over in OpenBSD-land's got a sense of humour...

uxer

https://www.c0ffee.net/blog/openbsd-on-a-laptop/

Add your user to the staff group. This group has higher resource limits in login.conf. You'll need to log out and back in for this change to take effect.
usermod -G staff YOUR_USERNAME

Is it correct?
Members of staff group or those of the class staff? userinfo YOUR_USERNAME has separate fields for groups and class. Shouldn't the command be:
usermod -L staff YOUR_USERNAME

https://youtu.be/EGdSfn-gDgI?t=1301
recommends -L, not -G

And Solene Rapenne speaks classes:

https://marc.info/?l=openbsd-misc&m=154988553609718&w=2

added my user to the "staff" group, which should have increased limits

https://marc.info/?l=openbsd-misc&m=154989223812300&w=2

The names in login.conf are classes, this is not related to groups.

uxer

https://man.openbsd.org/OpenBSD-7.1/login.conf#DESCRIPTION

In case the /etc/login.conf.d/${class} file exists, it will take precedence over the same login class defined in /etc/login.conf.

Will capabilities of a record be merged, duplicates preferred from /etc/login.conf.d/${class} over /etc/login.conf
or will the record from /etc/login.conf be discarded in favor to /etc/login.conf.d/${class}?
E.g., /etc/login.conf:

staff:\
        :datasize-cur=1536M:\
        :datasize-max=infinity:\
        :maxproc-max=1024:\
        :maxproc-cur=512:\
        :openfiles-max=8192:\
        :openfiles-cur=4096:\
        :stacksize-cur=32M:\
        :ignorenologin:\
        :requirehome@:\
        :tc=default:

and /etc/login.conf.d/staff:

staff:\
        :datasize-cur=1024M:\

Then, which will be the result, this (merging while preferring capabilities from /etc/login.conf.d/staff):

staff:\
        :datasize-cur=1024M:\
        :datasize-max=infinity:\
        :maxproc-max=1024:\
        :maxproc-cur=512:\
        :openfiles-max=8192:\
        :openfiles-cur=4096:\
        :stacksize-cur=32M:\
        :ignorenologin:\
        :requirehome@:\
        :tc=default:

or this (discarding record from /etc/login.conf and only respecting /etc/login.conf.d/staff):

staff:\
        :datasize-cur=1024M:\

In other words, do we need to type more in /etc/login.conf.d/${class} since it doesn't inherit values from /etc/login.conf?

If a capability/value is omitted, what value will be used by the system?

uxer

rvp

uxer Will capabilities of a record be merged, duplicates preferred [...]

This one you should be able to figure out on your own. Make duplicate capabilities (and records) and see what's merged and what's updated.

I would expect such info in the docs...

Me, I have tried it with getcap, like this:
getcap -c path= -f /etc/login.conf:/etc/login.conf.d/default default
getcap -c path= -f /etc/login.conf.d/default:/etc/login.conf default

And I am 😖 even more. getcap doesn't resolve values properly.
A simple example:

$ getcap -f /etc/login.conf xenodm
xenodm:	:openfiles=512:	:	:ignorenologin:	:datasize=infinity:	:maxproc=infinity:	:openfiles-max=1024:	:openfiles-cur=128:	:stacksize-cur=8M:	:	:path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin /usr/local/sbin:	:umask=022:	:datasize-max=1024M:	:datasize-cur=1024M:	:maxproc-max=256:	:maxproc-cur=128:	:openfiles-max=1024:	:openfiles-cur=512:	:stacksize-cur=4M:	:localcipher=blowfish,a:	:auth=passwd,skey:	:auth-ftp=passwd:

Here, we have:

openfiles=512 from xenodm
openfiles-max=1024 from daemon
openfiles-cur=128 from daemon
openfiles-max=1024 from default
openfiles-cur=512 from default

whereas if it did resolved, it would print only either:

openfiles=512

openfiles-max=512
openfiles-cur=512

without 128 & 1024

so 🤷‍♂️

I could speculate that the first encountered value is effective, and further duplicates are discarded, but why doesn't getcap do it?

deprecated text hides here

My observations of how getcap works as a pseudocode (tc logic omitted):

foreach file in ARGS[-f]
    if file !exists
        next file loop
    else if file exists
        read file
        if record ARGS[record] !exists
            next file loop
        else if record ARGS[record] exists
            if capability ARGS[-c] !exists
                skip
            else if capability ARGS[-c] exists
                get capability value

            exit 0

getcap iterates over files until it finds the record; when getcap has found the record in a file, it stops iterating over files and reads only this file record capabilites. So if a capability is not specified in the first file, then you will not get any value, even if that same capability for this record has been specified in a further file.
No merging - keep it stupid simple.

According to getcap, tc interpolation/expansion/inheriting works, even across multiple files. But you can't tc the same record name:

default:\
  :tc=default: 
# getcap: unable to lookup default

But you can inherit the same record name indirectly:
/etc/login.conf.d/default:

default:\
  :tc=pbuild:

while in /etc/login.conf:

pbuild:\
  :tc=default:

Indeed:

cgetent bugs

There are no checks for tc= name loops in cgetent().

deprecated text hides here

Then, while trying:
cap_mkdb -v -f /tmp/login.conf.1 /etc/login.conf /etc/login.conf.d/default
cap_mkdb -v -f /tmp/login.conf.2 /etc/login.conf.d/default /etc/login.conf
it said cap_mkdb: ignored duplicate: default which may mean cap_mkdb discards records from further files, similar to getcap.
It would be nice to peek into the .db, especially given that:

man cap_mkdb

The “tc” capabilities of the records are expanded before the record is stored into the database.

But I don't know how - it refers to cgetent(3) and c is even unreadable to me.

So again, what if you miss some important capability in your custom login.conf.d/${class}?

uxer

/etc/login.conf:
comment to default:

Any value changed in the daemon class should be reset in default class

comment to daemon:

Be sure to reset these values to system defaults in the default class!

😖 Please explain in plain English. What? Why?
What if one changes values in the daemon class without resetting them in the default class?
Only these 2, or staff and others might involve adjusting too? Why the daemon-default pair is affected whereas staff-default is not?

rvp

uxer I would expect such info in the docs...

cgetent (Section: Capability database semantics) does describe the behaviour of getcap. And, from my testing, it works as the man-page specifies--if it didn't, then it would be a bug.

Try these simple sample files for testing:

1.conf

sample:\
    :x=1:

2.conf

new:\
    :tc=sample:\
    :x=2:\
    :y=10:

3.conf

new:\
    :x=2:\
    :y=10:

uxer

uxer Thus, getcap is rather a "parse & dump" utility then "parse & resolve" one

uxer

rvp uxer I would expect such info in the docs...

cgetent (Section: Capability database semantics) does describe the behaviour of getcap.

Hm, that looks more like docs for devs or advanced admins. I would expect man login.conf.d for ordinary users, with user-targeted explanations of resolution process and real-world examples...

uxer
OK, I seem to eventually have figured it out.

When you run it like this:

getcap -f /etc/login.conf.d/<class>:/etc/login.conf <class>

It does dump everything, including duplicates, for the <class>, in the order it has found them.

rvp When a database is searched for a capability record, the first matching record in the search is returned.
When a record is scanned for a capability, the first matching capability is returned; the capability
:nameT@: will hide any following definition of a value of type T for name; and the capability :name@:
will prevent any following values of name from being seen.

In output of getcap without -c, all following definitions/values are present:

0.conf:

default:\
  :aa>0:

1.conf:

hide-prevent:\
  :aa@:\
  :tc=default:

getcap -f /tmp/getcap/1.conf:/tmp/getcap/0.conf hide-prevent
# hide-prevent:  :aa@:  :  :aa>0:

It dumps.

And when you are more specific:

getcap -c <capability>= -f /etc/login.conf.d/<class>:/etc/login.conf <class>

It does resolve and prints a single resulting value (my guess is it just prints the first encountered value from the order in which it has found them).
A special case - value is "@":

getcap -c aa -f /tmp/getcap/1.conf:/tmp/getcap/0.conf hide-prevent
# no output

So, for tracing capabilities across multiple files, one can't do it with one general getcap command (as I had tried and been confounded), one needs to check them one-by-one with -c <capability><type>

Yet it does NOT resolve the actual final value:

getcap -c openfiles -f /etc/login.conf xenodm
# 512 (from xenodm)

getcap -c openfiles-max -f /etc/login.conf xenodm
# 1024 (from daemon)

getcap -c openfiles-cur -f /etc/login.conf xenodm
# 128 (from daemon)

If it did resolve, all 3 would print 512 since openfiles alone means both -cur&-max.
So one still needs some manual mental math...

Looking at how getcap works, I dare to say this is not a properly implemented database tool, it is a hacky makeshift workaround of returning a substring, unless substring equals "@":

getcap -c openfile -f /etc/login.conf xenodm
# s=512
getcap -c openfil -f /etc/login.conf xenodm
# es=512
getcap -c openfi -f /etc/login.conf xenodm
# les=512

getcap -c openfiles=5 -f /etc/login.conf xenodm
# 12
getcap -c openfiles=51 -f /etc/login.conf xenodm
# 2

getcap -c a -f /tmp/getcap/1.conf:/tmp/getcap/0.conf hide-prevent
# a@

Keep it stupid simple 🤔

@rvp thanks for your care and effort, you are very helpful 💎

rvp

uxer It should parse and resolve. Note this para.:

When a database is searched for a capability record, the first matching record in the search is returned.
When a record is scanned for a capability, the first matching capability is returned; the capability
:nameT@: will hide any following definition of a value of type T for name; and the capability :name@:
will prevent any following values of name from being seen.

rvp

uxer my guess is it just prints the first encountered value from the order in which it has found them

Correct.

uxer Yet it does NOT resolve the actual final value:

If xenodm is present in /etc/login.conf and brings in daemon, it should. In 6.9 for the bgpd record:

default:\
        [...]
        :maxproc-cur=128:\
        [...]
daemon:\
        [...]
        :openfiles-max=1024:\
        [...]
        :tc=default:

bgpd:\
        :openfiles=512:\
        :tc=daemon:

And:

$ getcap -c openfiles-max= -f /etc/login.conf bgpd
1024
$ getcap -c maxproc-cur= -f /etc/login.conf bgpd
128
$

Note that maxproc-cur is defined 2 levels up in default and the definition was found correctly.

uxer I dare to say this is not a properly implemented database tool, it is a hacky makeshift workaround

No, it's not SQL 😉. And, you should probably report that (it matching sub-strings instead of the entire capability string only).

uxer

rvp uxer Yet it does NOT resolve the actual final value:

it should

man login.conf

The resource limit entries (cputime, filesize, datasize, stacksize, coredumpsize, memoryuse, memorylocked, maxproc, and openfiles) actually specify both the maximum and current limits ... The maximum and current limits may be specified individually by appending a -max or -cur to the capability name (e.g., openfiles-max and openfiles-cur).

My reading of man login.conf is that if you specify openfiles, it sets both openfiles-cur and openfiles-max, and it supersedes all openfiles-cur and openfiles-max fromtc= references.
This is why I have written getcap doesn't resolve the actual final value - it doesn't take into account that 3 capabilities openfiles, openfiles-cur and openfiles-max are about 2 actual final limits: openfiles-cur and openfiles-max.
My reading of your comment is that openfiles-cur and openfiles-max fromtc= references still hold (perhaps as more specific ones), and openfiles is less favored (perhaps as more generic one).
?

rvp you should probably report that (it matching sub-strings instead of the entire capability string only)

You mean as in https://www.openbsd.org/faq/faq1.html#Bugs and https://marc.info/?l=openbsd-bugs ?
With my 2 reports:
https://marc.info/?l=openbsd-bugs&m=164071451918800&w=2
https://marc.info/?t=164429629700001&r=1&w=2
my experience has been: first one ignored, second one "this is not a bug and the behavior is obvious but if you want to enhance it then send a patch"
😟 patching c is beyond my capabilities (pun intended).
So I am quite wary of reporting something unless I know for sure it is broken...

rvp

uxer The xxx-max and -min are application-specific features (ie. nothing to do with capability databases at all).

uxer So I am quite wary of reporting something unless I know for sure it is broken...

Looks like this partial matching is a "feature and not a bug" too. You can put any single character after a capability name to indicate a type (usually just: =, #)... even letters. So, getcap -c ... returns "partial matches" because it assumes the last char. of the given capability is the type!

uxer

ulimit & sysctl may be utilized to check (after a relogin or a reboot) the effects of your login.conf tinkering

uxer

My /etc/login.conf is vanilla.
My /etc/login.conf.d/theuser:

theuser|the user of the machine:\
  :path=                        \
    /usr/bin                    \
    /bin                        \
    /usr/sbin                   \
    /sbin                       \
    /usr/X11R6/bin              \
    /usr/local/bin              \
    /usr/local/sbin             \
    /usr/games:                 \
  :maxproc-max=1024:            \
  :maxproc-cur=512:             \
  :openfiles-max=8192:          \
  :openfiles-cur=4096:          \
  :stacksize-cur=32M:           \
  :tc=staff:

From userinfo: class theuser

Seems to work...