[Samba] Is “obey pam restrictions” still supposed to work in Samba 4?

[Andrew Bartlett]

On Wed, 2021-02-10 at 22:03 +0100, Chentao Credungtao via samba wrote:
> Hi,
> 
> The up-to-date Samba doc says 
> (https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html) :
> 
> "When Samba 3.0 is configured to enable PAM support (i.e. --with-
> pam), 
> this parameter will control whether or not Samba should obey PAM's 
> account and session management directives."
> 
> Is this still supposed to work with Samba 4 ? I had some strange
> result, 
> it seems PAM's restrictions are enforced once, but then not anymore.

It should work, but not for this purpose.  The session managment hook
helps run things like pam_mkhomedir and the account hooks try to ensure
Samba stays in line with restrictions on (eg) ssh.

> 
> I tried to set up a file-size limitation on a Samba share. I'm not 
> talking about quotas, I'm talking about preventing users from
> storing 
> files that are bigger than 100MB, for example. I used 
> /etc/security/limits.conf for this.
> 
> It almost works. Well, it works the first time a user tries to create
> a 
> file, and then not anymore.
> 
> 
> Here's what I did :
> 
>      - First I defined a hard filesize limit of 100MB for user
> johndoe 
> in /etc/security/limits.conf :    "johndoe    hard fsize    102400"
> 
>      - Then I added "session required pam_limits.so" to 
> /etc/pam.d/samba, in order to tell PAM to enforce the limitations
> 
>      - And finally, I added "obey pam restrictions = yes" to 
> /etc/samba/smb.conf

This actually causes quite a problem.  The last session setup to be
handled via this smbd process sticks, and it sets limits that interfere
with Samba's normal operation, not just user files.  It can limit the
number of files Samba can open for example.

> At first it seemed promising, when user johndoe tries to copy a file
> > 
> 100MB, a Windows 10 client throws the following error : An
> unexpected 
> error is keeping you from copying the file...An unexpected network
> error 
> occured

That would be Samba getting SIGXFSZ per man setrlimit:

      RLIMIT_FSIZE
              This  is the maximum size in bytes of files that the process may create.  Attempts to extend a file beyond this limit result in delivery of a SIGXFSZ
              signal.  By default, this signal terminates a process, but a process can catch this signal instead, in which case the  relevant  system  call  (e.g.,
              write(2), truncate(2)) fails with the error EFBIG.

> So far, so good ! That's what I wanted, prevent the user to store a
> file 
>  > 100MB
> 
> But if I click on "Try again", the file is copied anyway.

I'm not sure exactly why this happens, but it might be due to another
SMB session being created after and changing the limits again.  I'm not
sure, but we do know this behaviour (limits being read via PAM) is not
desired and need to remove it at some point. 

> And if I then try to copy more files > 100MB, no more error message
> is 
> thrown, and the copies proceed.
> 
> If user johndoe logs out and back in, same result : the first
> attempt 
> throws an error, the following attempts succeed.
> 
> So, it seems the restriction I set in /etc/security/limits.conf is
> only 
> enforced at the first attempt, and is no more enforced afterwards.
> 
> Any idea why ? Or any idea how I could achieve my goal (prevent a
> user 
> to copy a file > 100MB) ?

Not via this method.  I suggest overall file quotas, but that wouldn't
stop individual files growing.

Sorry!

Andrew Bartlett

-- 
Andrew Bartlett
https://samba.org/~abartlet/
Authentication Developer, Samba Team         https://samba.org
Samba Development and Support, Catalyst IT - Expert Open Source
Solutions
https://catalyst.net.nz/services/samba