estore the entire system state from a
> > > swap file, and carry on as if the cold boot was just a [firmware
> > > assisted] suspend/resume.
> > >
> > > So forging collisions is *not* a concern here. Let's avoid accidental
> > > or malicious, as those adjectives seem to confuse some people. The
> > > bottom line is that there is no need to protect against deliberate
> > > attempts to hide the fact that the memory map has changed, and so
> > > there is no reason to use cryptographic hashes here.
> > >
> > How about :
> >
> > The check is intended to differentiate between a resume (which expects
> > an identical e820 map to the one saved in suspend), and a cold boot
> > (which need not have an identical e820 map to that saved in suspend if
> > any was done at all). It is not necessary here to protect against
> > deliberate attempts to hide the fact that the memory map has changed, so
> > crc32 is sufficient for detection.
> >
>
> Almost. Hibernation always occurs after a cold boot, but usually, the
> E820 memory map happens to be the same.
>
> How about
>
> """
> The check is intended to detect whether the E820 memory map provided
> by the firmware after cold boot unexpectedly differs from the one that
> was in use when the hibernation image was created. In this case, the
> hibernation image cannot be restored, as it may cover memory regions
> that are no longer available to the OS.
>
> A non-cryptographic hash such as CRC-32 is sufficient to detect such
> inadvertent deviations.
> """
hash -> checksum
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
e would be called
> "accidental" changes, but sure, it could be changes that are "intentionally"
> made provided that the other side can be trusted to not try to avoid
> detection...), then a non-cryptographic checksum would be sufficient.
Wouldn't you also need a sign
about to be loaded into memory and the memory map used at the image
> creation time, because it is generally unsafe to load the image if the
> current memory map doesn't match the one used when it was created. so
> it is not intended as a cryptographic integrity check."
>
> And
t) changes the integrity check algorithm from md5 to
crc32. This integrity check is used only to verify accidental
corruption of the hybernation data and is not intended as a
cryptographic integrity check.
Md5 is overkill in this case and also disabled in FIPS mode because it
is known to be broken fo
On Thu, 2021-04-01 at 18:02 +0200, Rafael J. Wysocki wrote:
> On Thu, Apr 1, 2021 at 3:54 PM Ard Biesheuvel wrote:
> > On Thu, 1 Apr 2021 at 15:38, Rafael J. Wysocki wrote:
> > > On Thu, Apr 1, 2021 at 10:47 AM Ard Biesheuvel wrote:
> > > > On Tue, 30 Mar 20
On Thu, 2021-04-01 at 18:31 +0200, Rafael J. Wysocki wrote:
> On Thu, Apr 1, 2021 at 6:22 PM Simo Sorce wrote:
> > On Thu, 2021-04-01 at 18:02 +0200, Rafael J. Wysocki wrote:
> > > On Thu, Apr 1, 2021 at 3:54 PM Ard Biesheuvel wrote:
> > > > On Thu, 1 Apr 20
On Tue, 2021-03-30 at 21:45 +0200, Ard Biesheuvel wrote:
> On Tue, 30 Mar 2021 at 20:05, Simo Sorce wrote:
> > On Tue, 2021-03-30 at 16:46 +0200, Rafael J. Wysocki wrote:
> > > On Tue, Mar 30, 2021 at 12:14 AM Dexuan Cui wrote:
> > > > Hi,
> > > > MD
>
> > PS, currently it looks like FIPS mode is broken in the mainline:
> > https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg49414.html
FYI, SHA-1 is not a good choice, it is only permitted in HMAC
constructions and only for specified uses. If you need to change
algorithm you should go straight to SHA-2 or SHA-3 based hashes.
HTH,
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
On Fri, 2018-02-02 at 18:24 -0500, Paul Moore wrote:
> On Fri, Feb 2, 2018 at 5:19 PM, Simo Sorce wrote:
> > On Fri, 2018-02-02 at 16:24 -0500, Paul Moore wrote:
> > > On Wed, Jan 10, 2018 at 2:00 AM, Richard Guy Briggs
> > > wrote:
> > > > On 2018-01-0
On Fri, 2018-02-02 at 16:24 -0500, Paul Moore wrote:
> On Wed, Jan 10, 2018 at 2:00 AM, Richard Guy Briggs wrote:
> > On 2018-01-09 11:18, Simo Sorce wrote:
> > > On Tue, 2018-01-09 at 07:16 -0500, Richard Guy Briggs wrote:
> > > > Containers are a userspace concept
stem or you want to
correlate the system audit logs with other components dealing with
containers, now you need a place where you provide a mapping from your
audit u64 to the ID a container has in the rest of the system.
b) Now you need a mapping of some sort. The simplest way a container
orchestrator can go about this is to just use the UUID or Hash
representing their view of the container, truncate it to a u64 and use
that for Audit. This means there are some chances there will be a
collision and a duplicate u64 ID will be used by the orchestrator as
the container ID. What happen in that case ?
Simo.
--
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
On Tue, 2017-10-17 at 07:59 -0700, Casey Schaufler wrote:
> On 10/17/2017 5:31 AM, Simo Sorce wrote:
> > On Mon, 2017-10-16 at 21:42 -0400, Steve Grubb wrote:
> > > On Monday, October 16, 2017 8:33:40 PM EDT Richard Guy Briggs
> > > wrote:
> > > > There is su
ontainer ID means the process has
> the ability to indirectly control the audit trail.
The container Id can be used also for authorization purposes (by other
processes on the host), not just audit, I think this is why a separate
control has been proposed.
Simo.
--
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
The patch removes "WARNING: Prefer using '"%s...", __func__'
to using '', this function's name, in a string" warnings
reported by checkpatch.pl script.
Signed-off-by: Simo Koskinen
---
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
The patch removes "WARNING: Prefer using '"%s...", __func__'
to using '', this function's name, in a string" warnings
reported by checkpatch.pl script.
Signed-off-by: Simo Koskinen
---
drivers/staging/comedi/drivers.c | 4 ++--
1 file changed
Fixes if-statement related warning and errors reported
by checkpatch.pl
Signed-off-by: Simo Koskinen
---
drivers/staging/pi433/pi433_if.c | 253 +--
drivers/staging/pi433/rf69.c | 69 ++-
2 files changed, 148 insertions(+), 174 deletions(-)
diff
Removes following warnings found by checkpatch.pl script:
WARNING: Prefer using '"%s...", __func__' to using 'xxx',
this function's name, in a string
Signed-off-by: Simo Koskinen
---
drivers/staging/vt6655/card.c | 6 +++---
drivers/staging/vt6655/mac.c |
Fixed following warnings found by checkpatch.pl script:
WARNING: Prefer using '"%s...", __func__' to using '',
this function's name, in a string
Signed-off-by: Simo Koskinen
---
drivers/staging/rts5208/rtsx.c | 2 --
drivers/staging/rts5208/rts
Fixed following warnings found by checkpatch.pl script:
WARNING: Prefer using '"%s...", __func__' to using '',
this function's name, in a string
Signed-off-by: Simo Koskinen
---
drivers/staging/rts5208/rtsx.c | 2 +-
drivers/staging/rts5208/rtsx
Fixed issues found by checkpatch.pl and changed some dev_info()
function call to dev_dgb().
Signed-off-by: Simo Koskinen
---
drivers/staging/rts5208/rtsx.c | 8
drivers/staging/rts5208/rtsx_chip.c | 5 +++--
drivers/staging/rts5208/sd.c| 8
drivers/staging
On Fri, Jun 23, 2017 at 5:59 PM, Joe Perches wrote:
> On Fri, 2017-06-23 at 15:55 +0200, Simo Koskinen wrote:
>> Fixed some issues reported by checkpatch.pl script.
> []
>> diff --git a/drivers/staging/rts5208/rtsx.c b/drivers/staging/rts5208/rtsx.c
>> index b8177f5.
Fixed some issues reported by checkpatch.pl script.
Signed-off-by: Simo Koskinen
---
drivers/staging/rts5208/rtsx.c | 2 +-
drivers/staging/rts5208/rtsx_chip.c | 6 --
drivers/staging/rts5208/sd.c| 14 ++
drivers/staging/rts5208/spi.c | 11
lient (unsuccessfully)
> try
> to mount the server with krb5 where the server doesn't have the
> rpcsec_gss_krb5 module built."
>
> The problem is that rsci.cred is copied from a svc_cred structure
> that
> gss_proxy didn't properly initialize. Fix that.
Nice cat
Fixed coding style warnings reported by checkpatch.pl.
Signed-off-by: Simo Koskinen
---
drivers/staging/vt6656/rxtx.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/vt6656/rxtx.c b/drivers/staging/vt6656/rxtx.c
index 6341349..2609c1e 100644
t guids we'll still have that mapping
> > problem
> > anyway.
> Agreed, but, one step at a time? My impression is that the Samba
> people
> still consider this a step forward for Linux compatibility.
It is a step forward, but being able to store SIDs in the ACL, would be
http://vger.kernel.org/majordomo-info.html
I touched this code relatively recently, and this check looks correct.
Feel free to add Reviewed-by: Simo Sorce
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
file
> descriptor / socket was "created".
Given we are creating a new interface ... should we just send both the
cgroup at creation time and (optionally, if it differs) the cgroup the
process has at sendmsg() time, and let the peer sort out which one it is
interested in ?
Simo.
--
To un
On Thu, 2014-04-17 at 14:50 -0400, Vivek Goyal wrote:
> On Thu, Apr 17, 2014 at 02:23:33PM -0400, Simo Sorce wrote:
> > On Thu, 2014-04-17 at 10:35 -0700, Andy Lutomirski wrote:
> > > On Thu, Apr 17, 2014 at 10:33 AM, Simo Sorce wrote:
> > > > On Thu, 2014-04-17 a
On Thu, 2014-04-17 at 12:06 -0700, Andy Lutomirski wrote:
> On Thu, Apr 17, 2014 at 11:57 AM, Vivek Goyal wrote:
> > On Thu, Apr 17, 2014 at 02:50:23PM -0400, Vivek Goyal wrote:
> >> On Thu, Apr 17, 2014 at 02:23:33PM -0400, Simo Sorce wrote:
> >> > On Thu, 2
On Thu, 2014-04-17 at 11:04 -0700, Andy Lutomirski wrote:
> On Thu, Apr 17, 2014 at 10:52 AM, Simo Sorce wrote:
> > On Thu, 2014-04-17 at 10:26 -0700, Andy Lutomirski wrote:
> >> On Thu, Apr 17, 2014 at 10:12 AM, Vivek Goyal wrote:
> >> > On Thu, Apr 17, 2014 at 09:
On Thu, 2014-04-17 at 10:35 -0700, Andy Lutomirski wrote:
> On Thu, Apr 17, 2014 at 10:33 AM, Simo Sorce wrote:
> > On Thu, 2014-04-17 at 10:26 -0700, Andy Lutomirski wrote:
> >>
> >> Not really. write(2) can't send SCM_CGROUP. Callers of sendmsg(2)
> >
On Thu, 2014-04-17 at 10:26 -0700, Andy Lutomirski wrote:
> On Thu, Apr 17, 2014 at 10:12 AM, Vivek Goyal wrote:
> > On Thu, Apr 17, 2014 at 09:55:08AM -0700, Andy Lutomirski wrote:
> >> On Thu, Apr 17, 2014 at 9:48 AM, Simo Sorce wrote:
> >> > On Thu, 2014-04-17 a
On Thu, 2014-04-17 at 10:35 -0700, Andy Lutomirski wrote:
> On Thu, Apr 17, 2014 at 10:33 AM, Simo Sorce wrote:
> > On Thu, 2014-04-17 at 10:26 -0700, Andy Lutomirski wrote:
> >>
> >> Not really. write(2) can't send SCM_CGROUP. Callers of sendmsg(2)
> >
On Thu, 2014-04-17 at 10:26 -0700, Andy Lutomirski wrote:
> On Thu, Apr 17, 2014 at 10:12 AM, Vivek Goyal wrote:
> > On Thu, Apr 17, 2014 at 09:55:08AM -0700, Andy Lutomirski wrote:
> >> On Thu, Apr 17, 2014 at 9:48 AM, Simo Sorce wrote:
> >> > On Thu, 2014-04-17 a
On Thu, 2014-04-17 at 09:37 -0700, Andy Lutomirski wrote:
> On Thu, Apr 17, 2014 at 9:24 AM, Simo Sorce wrote:
> > On Thu, 2014-04-17 at 09:11 -0700, Andy Lutomirski wrote:
> >>
> >> No. The logging daemon thinks it wants to know who the writer is, but
> >&
On Thu, 2014-04-17 at 09:11 -0700, Andy Lutomirski wrote:
> On Thu, Apr 17, 2014 at 9:04 AM, Simo Sorce wrote:
> > On Thu, 2014-04-17 at 08:41 -0700, Daniel J Walsh wrote:
> >> On 04/16/2014 11:59 AM, Vivek Goyal wrote:
> >> > On Wed, Apr 16, 2014 at 11:13:31A
r* of the information.
It doesn't matter at all if the owner turns around and passes the socket
to another process anywhere in the system. If that process does it, it
means it wants to disclose information to which it already have access
to and can ship to said process already and independently anyway.
This use case wants to use SO_PEERCGROUP for that reason.
I hope this makes the use cases more clear.
Simo.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ear them,
but they need to be clear and circumstanced.
Simo.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Wed, 2014-04-16 at 09:31 -0700, Andy Lutomirski wrote:
> On Wed, Apr 16, 2014 at 9:13 AM, Simo Sorce wrote:
> > On Wed, 2014-04-16 at 07:37 -0700, Andy Lutomirski wrote:
> >> On Wed, Apr 16, 2014 at 5:57 AM, David Miller wrote:
> >> >
> >> > Pleas
On Wed, 2014-04-16 at 12:21 -0400, Tejun Heo wrote:
> Hello,
>
> On Wed, Apr 16, 2014 at 12:13:57PM -0400, Simo Sorce wrote:
> > The only one that *may* be reasonable is the "secret" cgroup name one,
> > however nobody seem to come up with a reason why it is legitim
ly try to. So just adding the ABI may break
> existing assumptions that are relevant to security or correctness.
It's not clear to me what you mean by this, either you explicitly use
SO_PASSCGROUP or not, it's not like you can involuntarily add a flag ...
Simo.
--
To unsubscribe from
gt; > not see any significant performance impact of this change.
>
> This is odd. Shouldn't an SCM_CGROUP cmsg be generated when the
> receiver has SO_PASSCGROUP set and the sender passes SCM_CGROUP to
> sendmsg?
What would be the point ?
Simo.
--
To unsubscribe from this
On Thu, 2014-03-13 at 10:55 -0700, Andy Lutomirski wrote:
>
> So give each container its own unix socket. Problem solved, no?
Not really practical if you have hundreds of containers.
Simo.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Thu, 2014-03-13 at 10:55 -0700, Andy Lutomirski wrote:
> On Thu, Mar 13, 2014 at 10:51 AM, Simo Sorce wrote:
> > On Wed, 2014-03-12 at 19:12 -0700, Andy Lutomirski wrote:
> >> On Wed, Mar 12, 2014 at 6:43 PM, Simo Sorce wrote:
> >> > On Wed, 2014-03-12 at 18:2
On Thu, 2014-03-13 at 10:25 -0700, Andy Lutomirski wrote:
> On Thu, Mar 13, 2014 at 9:33 AM, Simo Sorce wrote:
> > On Thu, 2014-03-13 at 11:00 -0400, Vivek Goyal wrote:
> >> On Thu, Mar 13, 2014 at 10:55:34AM -0400, Simo Sorce wrote:
> >>
> >> [..]
> >>
On Wed, 2014-03-12 at 19:12 -0700, Andy Lutomirski wrote:
> On Wed, Mar 12, 2014 at 6:43 PM, Simo Sorce wrote:
> > On Wed, 2014-03-12 at 18:21 -0700, Andy Lutomirski wrote:
> >> On Wed, Mar 12, 2014 at 6:17 PM, Simo Sorce wrote:
> >> > On Wed, 2014-03-12 at 14:1
On Thu, 2014-03-13 at 11:00 -0400, Vivek Goyal wrote:
> On Thu, Mar 13, 2014 at 10:55:34AM -0400, Simo Sorce wrote:
>
> [..]
> > > > This might not be quite as awful as I thought. At least you're
> > > > looking up the cgroup at connection time instead
apabilities, etc...).
> Process A exits. Container gets removed from system and new one gets
> launched which uses same cgroup as old one. Now process B sends a new
> request and SSSD will serve it based on policy of newly launched
> container.
>
> This sounds very similar to pid
On Wed, 2014-03-12 at 18:21 -0700, Andy Lutomirski wrote:
> On Wed, Mar 12, 2014 at 6:17 PM, Simo Sorce wrote:
> > On Wed, 2014-03-12 at 14:19 -0700, Andy Lutomirski wrote:
> >> On Wed, Mar 12, 2014 at 2:16 PM, Simo Sorce wrote:
> >>
> >> >
> >> &
On Wed, 2014-03-12 at 14:19 -0700, Andy Lutomirski wrote:
> On Wed, Mar 12, 2014 at 2:16 PM, Simo Sorce wrote:
> > On Wed, 2014-03-12 at 14:12 -0700, Andy Lutomirski wrote:
> >> On Wed, Mar 12, 2014 at 2:00 PM, Andy Lutomirski
> >> wrote:
> >> > On
reated it.
I think you do not understand how this whole problem space works.
The problem is exactly the same as with SO_PEERCRED, so we are taking
the same proven solution.
Connection time is all we do and can care about.
Simo.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ge mistake to me.
I am not sure where you are going, the program that want's to know about
the cgroup is outside the group.
> If you want to know where in the process hierarchy a message sender is,
> add *that* and figure out how to fix the races (it shouldn't be that hard).
What is
eyring
> \___ _uid_p.5001 keyring
> \___ krb keyring
> | \___ tkt785 big_key
> | \___ tkt12345 big_key
> \___ afs keyring
> \___ afs.redhat.com rxrpc
>
LOC_NOT_IN_QUOTA,
> > + ns->krb_cache_register);
> > + up_write(&ns->krb_cache_register_sem);
> > + if (!IS_ERR(krb)) {
> > + krb_ref = make_key_ref(krb, true);
> > + goto found;
> > + }
> > +
> &
On Thu, 2013-08-01 at 14:55 -0400, Daniel Kahn Gillmor wrote:
> On 08/01/2013 02:29 PM, Simo Sorce wrote:
>
> > It's called 'abstraction' :-)
>
> Good, I like abstraction :)
>
> >> It seems like a non-privileged user could use this to store arbitrary
this an intentional side effect?
Just as a user can add data into a shm segment ?
Is there any difference ?
> Sorry if these are obvious questions. feel free to point me to
> already-documented answers if they exist.
There isn't much documentation, but it is certainly good to sort out any
On 06/15/2013 07:05 AM, Jeff Layton wrote:
On Fri, 14 Jun 2013 07:52:44 -0400
Simo wrote:
On 06/13/2013 04:26 PM, Jeff Layton wrote:
The only real solution I can think of is to put flock locks into the
blocked_list/blocked_hash too, or maybe giving them a simple hlist to
sit on.
I'l
On Wed, 2013-05-29 at 18:56 +0200, Andi Kleen wrote:
> On Wed, May 29, 2013 at 12:18:09PM -0400, Simo Sorce wrote:
> > On Wed, 2013-05-29 at 11:55 -0400, Waiman Long wrote:
> >
> > > My patch set consists of 2 different changes. The first one is to avoid
> >
and
should not be brought up as a point in favor.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
> >> Instead of gss_mech_get_by_OID(), I suspect you want
> >> rpcauth_get_pseudoflavor(), but I haven't looked at the gssproxy code.
> >
> > It's doing
> >
> > status = -EOPNOTSUPP;
> > gm = gss_mech_get_by_OID(&ud
o me.
> >
> > I've now pulled the rpcsec_gss changes into the nfs-for-next. The main
> > reason why they were not pulled in earlier was due to uncertainty what
> > to do about the increase in "AUTH_GSS upcall timed out." syslog
> > warnings.
>
> Trond's n
On Mon, 2013-04-29 at 12:37 -0400, Chuck Lever wrote:
> On Apr 29, 2013, at 12:29 PM, Simo Sorce wrote:
>
> > On Mon, 2013-04-29 at 12:05 -0400, Chuck Lever wrote:
> >> On Apr 29, 2013, at 11:45 AM, "J. Bruce Fields"
> >> wrote:
> >>
> >&
to modify the gssproxy patches to use the new interfaces.
>
> > Also: it looks like 030d794bf498 "SUNRPC: Introduce
> > rpcauth_get_pseudoflavor()" is in Trond's linux-next, but not his
> > nfs-for-next. I'm not sure what that means--is it safe to rebase
On 03/05/2013 01:13 PM, J. Bruce Fields wrote:
On Mon, Mar 04, 2013 at 05:49:46PM -0500, Simo wrote:
On 03/04/2013 04:19 PM, J. Bruce Fields wrote:
On Thu, Feb 28, 2013 at 01:53:25PM -0800, Andy Lutomirski wrote:
[possible resend -- sorry]
On 02/28/2013 07:25 AM, Pavel Shilovsky wrote:
This
in Windows.
That may not be nice to a Unix system but what can you do ?
Simo.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
tion is reading a sparse file is
> >> transparent to the application. An application that is aware of
> >> sparse-files should determine whether its data set is suitable to be
> >> kept in a sparse file. After that determination is made, the
> >> application must
pular file systems which don't support sparse
> > files (e.g. FAT32 but there are many others) - in any case, writes
> > after end of file can take a LONG time if sparse files are not
> > supported and I don't know a good way for the client to know that
> > attribut
be
> > simply ignored (not implemented).
>
> NFS supports the deny-read and deny-write bits but not deny-delete.
>
> If we could do such opens in-kernel on local and clustered filesystems,
> that could also be useful for multi-protocol (Samba and NFS) and
> clustered ex
in lookup of %s",
> + cERROR(1, ("Error %d on cifs_get_inode_info in lookup of file",
> rc, full_path));
then please remove also full_path here
Simo.
--
Simo Sorce
Samba Team GPL Compliance Officer <[EMAIL PROTECTED]>
Senior
rvention,
then I agree with you.
I was just pointing out that the 2 protocols are not in fact completely
independent and this fact need to be properly considered and factored in
into this decision, nothing more, nothing less.
Simo.
--
Simo Sorce
Samba Team GPL Compliance Officer
email: [EMAIL PROT
On Thu, 2007-05-03 at 09:46 -0500, Gerald Carter wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Simo,
>
> > I guess DFS referrals can work cross protocol, so if you are redirected
> > from a longhorn server to a windoes 2000 or a samba server you want t
On Thu, 2007-05-03 at 15:43 +0100, Christoph Hellwig wrote:
> On Thu, May 03, 2007 at 10:36:53AM -0400, simo wrote:
> > I guess DFS referrals can work cross protocol, so if you are redirected
> > from a longhorn server to a windoes 2000 or a samba server you want to
> > be a
On Thu, 2007-05-03 at 15:17 +0100, Christoph Hellwig wrote:
> On Thu, May 03, 2007 at 09:21:29AM -0400, simo wrote:
> > Separate modules would mean the user have to know which protocol to
> > choose each time. And this make little sense.
>
> Of course it makes a lot of
ded and be able to pass all relevant data and
the network connection to the other.
Simo.
--
Simo Sorce
Samba Team GPL Compliance Officer
email: [EMAIL PROTECTED]
http://samba.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PR
ix extensions? Or "case sensitive = yes" ?
Simo.
--
Simo Sorce
Samba Team GPL Compliance Officer
email: [EMAIL PROTECTED]
http://samba.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
75 matches
Mail list logo
