similar to: Bug in initscripts-2.77-1.i386.rpm''s boot-up random # handler.

-----BEGIN PGP SIGNED MESSAGE----- The linux-alert-digest list has now been consolidated with the linux-alert list. There wasn''t nearly enough traffic on the linux-alert list to justify its having a separate digest list; subscribers to linux-alert-digest tended to receive the same number of e-mail messages as subscribers to linux-alert, only with an additional time lag of up to a

amd from the amd-920824upl102-6.i386.rpm file distributed with RedHat Linux 4.1 does not honor the nodev option for NFS filesystems and probably other mount types, allowing any user access to the device files in /dev on a system, provided that they have root access to another linux box on the network. In addition, the default amd.conf from RH 4.1 maps /net/* to NFS mounting, which makes the bug in

On 11/17/16 2:53 PM, Alex Crow via samba wrote: > >> From my understanding you seem to have Mac and Windows clients and are >> using the Samba machine as a fileserver. If the windows machines are >> joined to a domain, then you will probably be better off joining the >> Samba machine to the domain, this way you will not need the user map. >> >> It might help

On 11/10/16 1:13 PM, Josh Malone wrote: > Hello, > > Really stumped on this issue. I have samba 4.4.7 running on a new > server. Users cannot write to files to which they have write permissions > via group. > > Example: > > Here's the local filesystem on the samba server. I'm logged in as jmalone > > > : jmalone at canis; cd

On Fri, 18 Nov 2016 09:13:44 -0500 Josh Malone via samba <samba at lists.samba.org> wrote: > On 11/17/16 2:53 PM, Alex Crow via samba wrote: > > > >> From my understanding you seem to have Mac and Windows clients and > >> are using the Samba machine as a fileserver. If the windows > >> machines are joined to a domain, then you will probably be better >

All, Apologies for basically bumping my own thread, but I'm absolutely at my wits' end trying to figure out this access problem. I've replicated the issue with and without NFS being involved. On our old 4.0.25 server, users can write to files that they have group-based write permissions. On 4.5.x, 4.4.x, and 4.3.x that permission is not being honored. I would be incredibly

When the random-seed file is found, then avoid checking its existance again. --- customize/random_seed.ml | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/customize/random_seed.ml b/customize/random_seed.ml index e4c955e..1633aed 100644 --- a/customize/random_seed.ml +++ b/customize/random_seed.ml @@ -35,7 +35,7 @@ let rec set_random_seed (g : Guestfs.guestfs) root =

On 11/17/16 2:17 PM, Jeremy Allison wrote: > On Wed, Nov 16, 2016 at 03:25:24PM -0500, Josh Malone wrote: >> >> http://www.cv.nrao.edu/~jmalone/sambalog.txt > > Looking at that log I see: > > posix_get_nt_acl: called for file . > > canon_ace index 0. Type = allow SID = S-1-22-1-0 uid 0 (root) SMB_ACL_USER_OBJ ace_flags = 0x0 perms rwx > canon_ace index 1.

On Thu, May 26, 2016 at 01:45:05PM +0200, Pino Toscano wrote: > When the random-seed file is found, then avoid checking its existance > again. > --- > customize/random_seed.ml | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/customize/random_seed.ml b/customize/random_seed.ml > index e4c955e..1633aed 100644 > ---

Hello, Really stumped on this issue. I have samba 4.4.7 running on a new server. Users cannot write to files to which they have write permissions via group. Example: Here's the local filesystem on the samba server. I'm logged in as jmalone : jmalone at canis; cd /home/www.nrao.edu/content/logs/ : jmalone at canis; ls -l total 4 -rw-rw-r-- 1 jmalone nraoweb 0 Nov 10 10:02

CirrOS has its random-seed file in /etc. --- customize/random_seed.ml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/customize/random_seed.ml b/customize/random_seed.ml index 34a7af7..5a15ad9 100644 --- a/customize/random_seed.ml +++ b/customize/random_seed.ml @@ -30,6 +30,7 @@ let rec set_random_seed (g : Guestfs.guestfs) root = "/var/lib/systemd/random-seed"; (* Fedora

I''m looking for some evidence, backup up with dates and references, that shows that the Linux community responds to security problems more quickly than other OS vendors, and thus might be considered "more secure". A number of fairly high profile corporations are starting to look for such information as they consider Linux as an alternative solution to other UNIXes. Something

On Mon, Nov 14, 2016 at 11:38:52AM -0500, Josh Malone via samba wrote: > All, > > Apologies for basically bumping my own thread, but I'm absolutely at > my wits' end trying to figure out this access problem. I've > replicated the issue with and without NFS being involved. On our old > 4.0.25 server, users can write to files that they have group-based > write

On 11/14/16 6:32 PM, Jeremy Allison via samba wrote: > On Mon, Nov 14, 2016 at 11:38:52AM -0500, Josh Malone via samba wrote: >> All, >> >> Apologies for basically bumping my own thread, but I'm absolutely at >> my wits' end trying to figure out this access problem. I've >> replicated the issue with and without NFS being involved. On our old >>

On 11/15/16 7:25 PM, Jeremy Allison wrote: > > The token is the list of uids/gids (or SIDs in Windows terms) > that this smbd is using to represent the user right now. Okay - that makes sense. Thank you. >> >> canon_ace index 0. Type = allow SID = S-1-22-1-0 uid 0 (root) >> SMB_ACL_USER_OBJ ace_flags = 0x0 perms rwx >> canon_ace index 1. Type = allow SID =

On 11/16/16 8:44 AM, Josh Malone via samba wrote: > > Okay - so it's getting the right values for my user, but coming up with > the wrong permissions on the file I'm trying to access. Any idea why? > > I've been trying to debug this for days now - every build I make on Red > Hat Enterprise 6 does this. However, running Samba under Ubuntu server > behaves correctly

On 11/16/16 2:32 PM, Jeremy Allison via samba wrote: >> >> But the file is not root:root - it's owned by uid 12477 and group >> 9006. Why is Samba getting the wrong owner/group for this file? > > That is the core of your problem. What does the full debug level 10 > log say around this message ? > Nothing that I can see. In any case, I've resolved my issue.

On 11/18/16 9:53 AM, Rowland Penny via samba wrote: > > OK, can I suggest you stop using either a usermap or a userscript. Try > setting up your domain member correctly see here: With no usermap file or script, the behavior is the same: can't write to files you should be able to based on group membership. > > https://wiki.samba.org/index.php/Setup_Samba_as_an_AD_Domain_Member

Kali Linux is a Debian derivative, so add basic support for it by using most of the Debian code paths. The only exception is the crypto algorithm for passwords in passwd, which is always assumed as SHA512 (as Kali Linux is relatively new). --- customize/firstboot.ml | 2 +- customize/hostname.ml | 2 +- customize/password.ml | 2 +-

On 11/17/16 2:06 PM, Alex Crow via samba wrote: > >>> My AD account objects all have uidNumber and gidNumber set (we use >>> that for the Mac systems bound to AD). And the AD usernames match the >>> NIS usernames. (the uid/gids match too). >> This is probably why it works on Ubuntu, but not on Centos, sssd is >> probably running on the Centos machine, but